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


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

        

Reply via email to