Websphere 7 - universal match pattern ('/**') is defined before other patterns

[iojohnso]

I have generated a spring project using Roo, and used the security setup addon to add in the spring security. The security works fine on Tomcat 7, but am running into the following problem when trying to deploy to Websphere 7.0.0.19. I'm currently using Spring Security 3.1.0.RELEASE. I've seen other projects use the Spring DelegatingFilterProxy just fine within Websphere. Anybody have any ideas?

Error from StackTrace:

E org.springframework.web.context.ContextLoader initWebApplicationContext Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.security.filterChainProxy': Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: A universal match pattern ('/**') is defined  before other patterns in the filter chain, causing them to be ignored. Please check the ordering in your <security:http> namespace or FilterChainProxy bean configuration

applicationContext-security.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/security" 
    xmlns:beans="http://www.springframework.org/schema/beans" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
        http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.1.xsd"> 

    <!-- HTTP security configurations -->
    <http auto-config="true" use-expressions="true" >
        <form-login login-processing-url="/resources/j_spring_security_check" login-page="/login" authentication-failure-url="/login?login_error=t" />
        <logout logout-url="/resources/j_spring_security_logout" />
        <!-- Configure these elements to secure URIs in your application -->
        <intercept-url pattern="/login" access="permitAll" />
        <intercept-url pattern="/admin/**" access="hasRole('ROLE_ADMIN')" />
        <intercept-url pattern="/jobtypes/**" access="isAuthenticated()" />
        <intercept-url pattern="/tests/**" access="permitAll" />
        <!-- Websphere Problem: IllegalArgumentException: A universal match pattern ('/**') is defined  before other patterns in the filter chain -->
        <intercept-url pattern="/resources/**" access="permitAll" />
        <intercept-url pattern="/**" access="hasRole('ROLE_USER')" />
    </http>
    
    <!-- Configure Authentication mechanism -->
	<beans:bean name="myCompanyAuthenticationProvider" class="edu.mycompany.project.security.MyCompanyAuthenticationProvider" />
	<authentication-manager alias="authenticationManager">
		<authentication-provider ref="myCompanyAuthenticationProvider" />
	</authentication-manager>   
</beans:beans>

UPDATE:

I have confirmed the security config is getting loaded twice. I have uploaded my web.xml

Still not exactly sure why it is loading twice though. Will work in the forums on this. Thanks!

[Rob Winch]

For others that land on this thread. This was logged as SEC-2034 and determined to be invalid. The cause is that the configuration is being loaded twice (exact reasons still under investigation by the reporter).

[Rob Winch]

Are you importing the other configurations in an XML file in addition to having it being picked up in the web.xml (i.e. are you using <import /> within any of your configuration files)?

PS: Editing a post does not send a notification on the forums so it is best to make a new post (this way I know you have updated the thread)

[iojohnso]

I have found the culprit of the multiple config files loading twice. It has to do with how Spring Roo initially creates the web.xml file - an extra asterisk is added after classpath. I have opened a spring roo ticket here.

When the "web mvc setup" command is run, the web.xml is setup with the following path to the spring context files...

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath*:META-INF/spring/applicationContext*.xml</param-value>
</context-param>

The first asterisk is the culprit for the spring config files (-spring.xml specifically) being picked up multiple times when running on Websphere 7.0.0.19 (The app deploys fine on Tomcat however). After I remove that asterisk, then the application loads fine

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:META-INF/spring/applicationContext*.xml</param-value>
</context-param>

Is there a reason for the first asterisk? If not, please remove. Thanks!

[Rob Winch]

I would enable debug logging and see what files are getting loaded. Perhaps you have an XML file in a jar that is getting picked up.

[iojohnso]

Here are the two locations they are being picked up from.

org.springframework.beans.factory.xml.XmlBeanDefin itionReader loadBeanDefinitions Loading XML bean definitions from file...

C:\app_workspace_sts_workload\.metadata\.plugins\org.eclipse.wst.server.core\tmp1\workload\WEB-INF\classes\META-INF\spring\applicationContext-security.xml

C:\app_workspace_sts_workload\.metadata\.plugins\org.eclipse.wst.server.core\tmp1\workload\META-INF\spring\applicationContext-security.xml

So when the app is deploying it is pushing the applicationContext-security.xml to two different locations?

[Rob Winch]

It would appear that you either have the file in your project twice or it is being deployed twice. It appears you are using Eclipse to deploy your project to WAS. One thing that looks weird to me is that the file would normally be something like this:

C:\app_workspace_sts_workload\.metadata\.plugins\org.eclipse.wst.server.core\tmp1\wtpwebapps\workload\META-INF\spring\applicationContext-security.xml

Can you try building the web application (i.e. converting it to a WAR) and seeing if the resulting war contains the xml file twice? Since you are using Roo I assume it is a Maven project so you can just run mvn clean package to get the war. If the XML file is not in the resulting war twice it is probably an issue with the WAS WTP integration with Eclipse.