[
https://issues.apache.org/jira/browse/OWB-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Kaltepoth updated OWB-629:
------------------------------------
Attachment: OWB-629-first-try.patch
First version of a patch for this issue.
> NoClassDefFoundError for optional dependencies
> ----------------------------------------------
>
> Key: OWB-629
> URL: https://issues.apache.org/jira/browse/OWB-629
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.2
> Environment: Tomcat 7.0.22, JDK 1.6.0_23
> Reporter: Christian Kaltepoth
> Assignee: Gurkan Erdogdu
> Attachments: OWB-629-first-try.patch, owb-test-updated.zip,
> owb-test.zip
>
>
> Some of the Seam modules (like Seam Persistence) contain optional Maven
> dependencies. The persistence module for example declares Hibernate as an
> provided dependency. The Seam Persistence module contains only one single
> class that requires Hibernate which is an SPI implementation to support
> specific Hibernate features. This class is only loaded/used if Hibernate is
> detected. Furthermore it's important to know that this bean is not meant to
> be a bean manged by the CDI runtime. Therefore it is annotated with @Veto
> (Seam Solder API) to get vetoed during CDI startup.
> All this works very fine with Weld 1.1.x. Unfortunately OWB fails to deploy
> the Seam Persistence JAR with the following exception:
> SCHWERWIEGEND: Exception sending context initialized event to listener
> instance of class org.apache.webbeans.servlet.WebBeansConfigurationListener
> java.lang.NoClassDefFoundError: org/hibernate/TransientObjectException
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at
> org.apache.webbeans.util.ClassUtil.getClassFromName(ClassUtil.java:115)
> at
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.getBeanClasses(AbstractMetaDataDiscovery.java:209)
> at
> org.apache.webbeans.config.BeansDeployer.checkStereoTypes(BeansDeployer.java:732)
> at
> org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:160)
> at
> org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:127)
> at
> org.apache.webbeans.web.lifecycle.WebContainerLifecycle.startApplication(WebContainerLifecycle.java:88)
> at
> org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:85)
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4723)
> at
> org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5226)
> at
> org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5221)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> Caused by: java.lang.ClassNotFoundException:
> org.hibernate.TransientObjectException
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1678)
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1523)
> ... 17 more
> For me it looks like the class scanner tries to build a set of Class objects
> from all classes in the bean archive. But this fails as soon as the class
> compiled against the Hibernate API is picked up as Hibernate is not on the
> classpath.
> If I remember correctly Weld 1.0.x had similar issues. Somehow this was
> resolved in Weld 1.1.x but I don't know anything about the details.
> I think OWB could handle NoClassDefFoundErrors a bit nicer. Currently OWB
> doesn't support bean archives that have optional dependencies at all. So an
> archive that contains just one class for which not all dependencies (classes)
> are accessible from the ClassLoader completely fails to deploy using OWB.
> Even if this class isn't used at all (neither within CDI nor manually
> instantiated in the application code).
> I think it would be easy to fix this. ClassUtil.getClassFromName() or
> AbstractMetaDataDiscovery.getBeanClasses() could catch NoClassDefFoundError
> and handles them in some way. I think it would make sense to simply ignore
> such errors during the bean archive scanning process on continue with the
> next class.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
