Websphere 7 form-based authentication ignored when classloader order PARENT_LAST

I have a very simple web-application that integrates spring security with j2ee declarative security. The important parts of the web.xml are shown here:

<security-role>
    <role-name>ROLE_USER</role-name>
</security-role>
<security-role>
    <role-name>ROLE_SUPERVISOR</role-name>
</security-role>

<security-constraint>
    <web-resource-collection>
        <web-resource-name>All Resources</web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>ROLE_USER</role-name>
        <role-name>ROLE_SUPERVISOR</role-name>
    </auth-constraint>
</security-constraint>   

<login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
        <form-login-page>/login.html</form-login-page>
        <form-error-page>/accessdenied.html</form-error-page>
    </form-login-config>
</login-config>

This works exactly as expected in Tomcat 6.0.33 and Glassfish 3.1.1. When I migrated the same app to Websphere 7.0.0.17, I noticed that I had to reverse the classloader order marking it as PARENT_LAST (because WAS embeds a really old version of commons-logging which breaks the webapp).

The behavior I expect is for WAS to redirect to the form-login-page when I request a resource in the webapp.

The behavior I'm seeing is that instead of websphere protecting the secured resources by presenting the login form, it proceeds directly to the "Access Denied" supplied by spring security from within the app.

I've also tried BASIC instead of FORM as the auth-method, and the results are the same.

Any ideas as to what I might be doing 开发者_JS百科wrong?

EDIT: Disabling Spring Security causes the declarative security to work as expected. This sort of leads to the conclusion that if I want the built-in LoginFilter to fire first, I'd have to explicitly declare it in my web.xml --giving me a dependency on WAS :O(

EDIT: I also discovered that WAS fires the filters declared in the app before applying declarative security; it happens this way regardless of the classloader order.

Notes: I have administrative security enabled, and properly mapped user roles, etc. I verified this using the "DefaultApp" that comes with websphere, the "snoop" servlet is protected, and the challenge seems to work as normal in that app.

Since you say the webapp is really simple, I'd go in a whole other direction: eliminating commons-logging from your dependencies and rely on the one from WAS. JCL is quite tough to root out from Websphere (see, for example, other such problem I tried to help with: Explanation of class loading in an EAR for non-requested but dependent class). The popular hint is to switch to PARENT_LAST, but considerable number of people report it does not work for them.

Go through your dependencies and see what relies of JCL; if you use "nodep" jars (self-contained with all depencencies packed), change them to single jars. Maven is a great helper for this, if you don't use it, it's down to manual work.