You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xbean-dev@geronimo.apache.org by "Kohsuke Kawaguchi (JIRA)" <ji...@apache.org> on 2007/01/23 23:59:49 UTC
[jira] Created: (XBEAN-71) qdox dies because it cannot resolve
javax/servlet/ServletContext
qdox dies because it cannot resolve javax/servlet/ServletContext
----------------------------------------------------------------
Key: XBEAN-71
URL: https://issues.apache.org/jira/browse/XBEAN-71
Project: XBean
Issue Type: Bug
Components: maven-plugin
Affects Versions: 2.7
Reporter: Kohsuke Kawaguchi
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (XBEAN-71) qdox dies because it cannot resolve
javax/servlet/ServletContext
Posted by "Dain Sundstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/XBEAN-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dain Sundstrom reassigned XBEAN-71:
-----------------------------------
Assignee: Dain Sundstrom
> qdox dies because it cannot resolve javax/servlet/ServletContext
> ----------------------------------------------------------------
>
> Key: XBEAN-71
> URL: https://issues.apache.org/jira/browse/XBEAN-71
> Project: XBean
> Issue Type: Bug
> Components: maven-plugin
> Affects Versions: 2.7
> Reporter: Kohsuke Kawaguchi
> Assignee: Dain Sundstrom
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (XBEAN-71) qdox dies because it cannot resolve
javax/servlet/ServletContext
Posted by "Dain Sundstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/XBEAN-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573476#action_12573476 ]
Dain Sundstrom commented on XBEAN-71:
-------------------------------------
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.
> qdox dies because it cannot resolve javax/servlet/ServletContext
> ----------------------------------------------------------------
>
> Key: XBEAN-71
> URL: https://issues.apache.org/jira/browse/XBEAN-71
> Project: XBean
> Issue Type: Bug
> Components: maven-plugin
> Affects Versions: 2.7
> Reporter: Kohsuke Kawaguchi
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.