qdox dies because it cannot resolve javax/servlet/ServletContext

• Key: XBEAN-71
• Type: Bug
• Status: Open
• Priority: Major
• Assignee: Dain Sundstrom
• Reporter: Kohsuke Kawaguchi
• Component/s: maven-plugin
• Affects Version/s: 2.7

Description

When one of my classes implement Spring's ServletContextAware interface, qdox used by XBean dies. The call stack below:

java.lang.NoClassDefFoundError: javax/servlet/ServletContext
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2365)
at java.lang.Class.privateGetPublicMethods(Class.java:2488)
at java.lang.Class.getMethods(Class.java:1406)
at com.thoughtworks.qdox.JavaDocBuilder.createBinaryClass(JavaDocBuilder.java:189)
at com.thoughtworks.qdox.JavaDocBuilder.getClassByName(JavaDocBuilder.java:119)
at com.thoughtworks.qdox.model.ClassLibrary.getClassByName(ClassLibrary.java:37)
at com.thoughtworks.qdox.model.Type.getJavaClass(Type.java:98)
at com.thoughtworks.qdox.model.JavaClass.getImplementedInterfaces(JavaClass.java:91)
at org.apache.xbean.spring.generator.QdoxMappingLoader.loadElement(QdoxMappingLoader.java:270)
at org.apache.xbean.spring.generator.QdoxMappingLoader.loadElements(QdoxMappingLoader.java:153)
at org.apache.xbean.spring.generator.QdoxMappingLoader.loadNamespaces(QdoxMappingLoader.java:107)
at org.apache.xbean.spring.generator.QdoxMappingLoader.loadNamespaces(QdoxMappingLoader.java:101)
at org.apache.xbean.maven.XBeanMojo.execute(XBeanMojo.java:153)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)

The root cause of this is in qdox, and for that I filed http://jira.codehaus.org/browse/QDOX-110

The reason this problem occurs is that maven-xbean-plugin depends on spring (via xbean-spring), so when qdox sees references to spring classes in my sources, it ends up loading that class in maven-xbean-plugin's classloader as java.lang.Class object (in the above case that was ServletContextAware.)

Yet the dependency specified in the xbean-spring module is

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
</dependency>

and this uber spring jar's POM doesn't declare any other dependency. So while introspecting methods and fields on ServletContextAware, it tries to load ServletContext, and it dies there.

This bug in qdox is particularly bad with maven-xbean-plugin because in maven-xbean-plugin, the sources that are being compiled are meant to be used with Spring. So there's a rather big chance of them using some Spring interfaces.

It looks like the workaround is to use more recent versions of spring, such as 1.2.8, whose POM includes all the additional dependencies.

Comments

[Dain Sundstrom]

Is this still a problem for you?

The trunk poms are currently using spring 2.0.5 and are using the modular spring jars instead of the uber jar. We have also marked our use of spring-web as optional so it should no longer be in the plugin class loader.