This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

The instructions and links worked for our cluster and j_security session issue. Our version is 6.1.0.15 and it worked. Thanks for the followup.

Hi inkspot23,
Could you give me some details on how you got this work on a cluster environment?
We are facing the situation where we can have this worked in our local environments using WAS 6.1.0.21, but when we deploy to production environment where we have a cluster environment, it does not work. The settings are the same on both environments: (1) Defining the custom property for Web container; (2) The fix pack PK33090 should already be included in WAS 6.1.0.21; (3) Classloaders set to PARENT_FIRST

Thank you very much in advance.

Comment

I have a web app that works on tomcat. But it does not work on both Websphere 6.1.0.17 and 6.1.0.21 with com.ibm.ws.webcontainer.invokefilterscompatibility set to true. It complains
Error 404: SRVE0190E: File not found: /j_spring_security_check. I'm not sure how to work around this one. Any help/advice would be much appreciated.

Comment

I have a web app that works on tomcat. But it does not work on both Websphere 6.1.0.17 and 6.1.0.21 with com.ibm.ws.webcontainer.invokefilterscompatibility set to true. It complains
Error 404: SRVE0190E: File not found: /j_spring_security_check. I'm not sure how to work around this one. Any help/advice would be much appreciated.

I'm in the same boat: a WAS 6.1.0.21 clustered environment. App & security work fine under Tomcat, do not in WebSphere.

I've set the com.ibm.ws.webcontainer.invokefilterscompatibility customer parameter to true and put a dummy "blank" j_acegi_security_check file in the root of the application.

So it's no longer throwing the file not found exception, but it throws the following error/stack trace:

Comment

Are you completely ignoring the first few lines of your own stack trace? The NPE you are getting is happening in your own code. Set a breakpoint and fire up the debugger.

Since the code works fine across multiple versions of Tomcat, I'm not convinced the problem is there.

The NPE is thrown the first time the user object stored in the session is referenced. So the symptom of a null user is just that.

The user object gets inserted into the session by a class that extends org.springframework.security.ui.webapp.Authenticat ionProcessingFilter. That part works (you can see that the onSuccessfulAuthentication method is called). So it ought to be available to the session.

Comment

The NPE is thrown the first time the user object stored in the session is referenced.

So is it the UserDetails object itself that is null? That's not clear from your description.

Also...

The HttpSessionContextIntegrationFilter has sole responsibility for retrieving any SecurityContext that's been cached in the HttpSession and then poking that into the SecurityContextHolder (which is essentially a threadbound container for your SecurityContext, which in turn contains an Authentication object, which in turn contains the UserDetails object).

When the NPE occurs in your code, how exactly are you accessing the UserDetails object? Are you grabbing it directly from the session yourself, or taking it from the SecurityContextHolder?

Can you post the code for the component that's throwing the NPE? That would help a lot.

Comment

After authenticating w/Spring Security, there is some legacy code that does a JNDI lookup. That lookup was failing immediately after the user was authenticated. I was thrown off by the filter unavailable error message - looking at the WAS logs uncovered the real problem.

Apologies if this is O/T but here is the fix I made to my lookup to work with both Tomcat 6.0.16 and WAS 6.1.0.21:

Comment

Not to belabor the issue, but you should consider using Spring to do the JNDI lookup. Then deploying to one server or another is just a config change and your code doesn't become coupled to your environment in any way.

Comment

I had exactly the same problem as people on this forum had: the 404 error-code whenever trying to login/logout of an application using Spring security. The error only occurred on WAS for me, but the same code worked fine on Tomcat, confirming this ISN'T a Spring security problem. The information provided by people in this thread was very useful in getting the problem fixed. Our WAS server was already at fixpack level 21, but the Websphere people in my company implemented the web container setting as suggested in this thread, and the problem magically disappeared.

Thanks

Comment

I had exactly the same problem as people on this forum had: the 404 error-code whenever trying to login/logout of an application using Spring security. The error only occurred on WAS for me, but the same code worked fine on Tomcat, confirming this ISN'T a Spring security problem. The information provided by people in this thread was very useful in getting the problem fixed. Our WAS server was already at fixpack level 21, but the Websphere people in my company implemented the web container setting as suggested in this thread, and the problem magically disappeared.

Allegedly this is a WebSphere "optimization." Without the web container property set, WebSphere thinks that anything not mapped in a servlet-mapping section of the web.xml is static content, so it "optimizes" this call by not even attempting to send it down the filter chain.

This used to work with WAS 5.x, in fact. Why is it that an optimization which breaks backward compatibility needs to be actively turned off with a web container setting? Why not require the optimization to be turned on with a setting instead? I'm sure that IBM has their reasons, but they are a mystery to me.

Just to re-iterate something I said earlier in this thread... another thing you can do if you don't want to go the web container property route is to enable administrative security and map the login URL to j_security_check (instead of j_spring_security check) and your logout URL to ibm_security_logout. When administrative security is enabled, WAS is smart enough to realize that these URLs are "special" and not static content.