ClassDefNotFound for tomcat app with META-INF/context.xml
Have run into an issue where I was getting lots of ClassDefNotFound classloader problems, but only when loading the app via IDEA launcher. If I drop the .war into tomcat and start it the application runs without issue. Also the classes it was saying where not present, where in WEB-INF/lib and the same .war functions (tried resetting my local maven cache anyway - which didn't help).
Turns it this webapp had a META-INF/context.xml file with a loader defintion in it:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<!--
This setting is for atmosphere, Comet functionality of navigator
to be able to run under Tomcat
<Loader className="org.atmosphere.util.AtmosphereClassloader"/>
-->
<Loader delegate="true"/>
</Context>
The Loader delegate="true" seems to be causing all the classloader problems when launching inside an embedded tomcat container? is that right? (tomcat 7.0.39 under centos 6.5).
Not sure why this is required here, app seems to have had atmosphere support at some point, I'm not sure if this loader/context is required for this app or not, but IDEA doesn't like it.
Please sign in to leave a comment.
To add a few more details to this, the error I get when webapp is deployed is of the kind:
This is a Spring-MVC app, so we have all the spring jars in WEB-INF/lib. However we also have cxf-bundle-2.5.1 which I know also contains copies of all the spring jars (albeit slightly different versions). Could the delegate loader be causing these to get confused? of could it be one of the other webapps loaded from the tomcat context? theres no spring jars in tomcat/lib. Or is the delegate context known to cause problems when launching from IDEA.
Not sure why adding the docbase to a tomcat conf/Catalina/localhost/myapp.xml and running same IDEA built artifact manually appears to work without any problems.
Probably not cxf-bundle, I was confused by maven dependency tree that's all. cxf-bundle pom includes the spring jars, but this projects primary pom includes a different version of those same spring jars so takes precedence. That shouldn't affect the deployment stage, not after web exploded artifact has been built.