Problem with "multi-threaded" security context

[stoneskin]

We have a Web Services project which utilises services exposed by separately deployed application.

The services are accessed via httpinvoker, and it works a treat.

Authentication is achieved with

final Authentication authentication =
new UsernamePasswordAuthenticationToken(username, password);
SecurityContextHolder.getContext().setAuthenticati on(authentication);

This works with no problems.

However within our Web Services project we have a jsp page that is used to verify that the project has deployed correctly, i.e. this is primarily for internal use though it could be used to check a deployment on a client's box.

This verify.jsp sits in the WEB-INF root.

verify.jsp currently attempts to access some utility services in the other application, also via httpinvoker.

To get this working I have a simple test:

<%
WebApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContex t(application);
IConfigurationHelper helper = (IConfigurationHelper)ctx.getBean("configurationHe lper");
java.lang.String something = helper.getSomething();
%>

"configuationHelper" is a bean declared within the Web Services application, and this also has the same authenticaton code:

final Authentication authentication =
new UsernamePasswordAuthenticationToken(username, password);
SecurityContextHolder.getContext().setAuthenticati on(authentication);

However it falls over in a heap with complaining that "authentication" is null.

As a quick test, I used the line:

SecurityContextHolder.setStrategyName(SecurityCont extHolder.MODE_GLOBAL);

So this implies that there is some form of multi-threading going on. But we cannot do the above for obvious reasons - this configuation helper sits on the middle tier, i.e. it is not a client-side class and therefore the SecurityContextHolder has to be LOCAL.

Can anyone suggest anything? Why is the same bean accessed from the JSP seemingly using a different Security Context?

Thanks

[stoneskin]

I have a number of servlets defined in web.xml with different url patterns. Could it be that as the JSP path does not fit one of these patterns it is provided with a different context thread?