> 2010-02-26 14:04:43,080 ERROR 
> [org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/cas]] - 
> SafeDispatcherServlet:
The Spring DispatcherServlet we wrap threw on init.
But for our having caught this error, the servlet would not have initialized.
org.springframework.beans.PropertyBatchUpdateException; nested
PropertyAccessException details (1) are:
PropertyAccessException 1:
org.springframework.beans.MethodInvocationException: Property
'publishContext' threw exception; nested exception is
java.lang.reflect.MalformedParameterizedTypeException

My hunch is this is a problem with SafeDispatcherServlet itself that
is caused by changes to the underlying Spring FrameworkServlet,
http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/servlet/FrameworkServlet.html.
 What's interesting is that we use SafeDispatcherServlet in our
customized CAS instance, and I got a clean deploy yesterday afternoon
after upgrading to 3.4-RC1.  We use the LDAP integration module for
auth as well.

My best guess is that there's some other startup problem in this
scenario that's exercising the error handling code path of
SafeDispatcherServlet, and it's failing in a way that masks the
underlying problem.  I did some further investigation to support this
idea.  I replaced SafeDispatcherServlet with DispatcherServlet and got
a clean deploy, but when I attempted to browse to /cas/, the following
is displayed in the browser:

javax.servlet.ServletException: Servlet.init() for servlet cas threw exception
        
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
        
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
        
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:857)
        
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:565)
        org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1509)
        java.lang.Thread.run(Thread.java:613)

root cause

java.lang.NoSuchFieldError: APPLICATION_CONTEXT_ID_PREFIX
        
org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:431)

Brief Googling turned up this thread,
http://forum.springsource.org/showthread.php?p=274549, which fingered
different Spring versions as the culprit.  Sure enough, WEB-INF/lib in
the deployable built with maven-war-overlay has a mix of spring jars:

marvin:~/apps/tomcat/webapps$ ls cas/WEB-INF/lib/spring*
cas/WEB-INF/lib/spring-aop-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-asm-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-beans-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-binding-2.0.8.RELEASE.jar
cas/WEB-INF/lib/spring-context-2.5.6.SEC01.jar
cas/WEB-INF/lib/spring-context-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-context-support-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-core-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-expression-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-jdbc-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-js-2.0.8.RELEASE.jar
cas/WEB-INF/lib/spring-ldap-core-1.3.0.RELEASE.jar
cas/WEB-INF/lib/spring-ldap-core-tiger-1.3.0.RELEASE.jar
cas/WEB-INF/lib/spring-orm-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-security-cas-client-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-security-config-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-security-core-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-security-web-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-tx-2.5.6.jar
cas/WEB-INF/lib/spring-tx-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-web-2.5.6.SEC01.jar
cas/WEB-INF/lib/spring-web-3.0.1.RELEASE.jar
cas/WEB-INF/lib/spring-webflow-2.0.8.RELEASE.jar
cas/WEB-INF/lib/spring-webmvc-3.0.1.RELEASE.jar

I'm at a loss to explain the inclusion of mixed spring jars.  The
cas.war built in cas3/cas-server-webapp contains exclusively
3.0.1.RELEASE in WEB-INF/lib.  Additionally, mvn dependency:list on
the cas-server-support-ldap module shows exclusively 3.0.1.RELEASE
dependencies.  Suggestions for why we're getting a mix when using
maven-war-overlay plugin are welcome.

In summary it looks like we've got two problems here:

 1. Problem with SafeDispatcherServlet error handling
 2. Mixed Spring jars when using maven-war-overlay in some cases

M

-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-dev

Reply via email to