Hi Christian! @Optional is not specified in CDI-1.0. So this relies on a non-portable assumption. I already created a CDI spec issue for it.
*search search* Oki, the ralted issues are https://issues.jboss.org/browse/CDI-35 https://issues.jboss.org/browse/CDI-50 I now reopened CDI-50 because the proposed solution in CDI-50 is imo not implementable. I just don't know how I should implement @Optional(Foo.class) when Foo.class is not available ^^ This makes too many assumptions on the ClassScanning and ClassLoading which would turn out not being portable and even not implementable on some systems I fear. The best bet is to split those parts into own jars for CDI-1.0 compatibility. LieGrue, strub ----- Original Message ----- > From: Christian Kaltepoth <[email protected]> > To: [email protected] > Cc: > Sent: Wednesday, November 16, 2011 9:28 AM > Subject: NoClassDefFoundError for optional dependencies > > Hey all, > > I just started to debug some compatibility problems between OWB and > SeamFaces. Unfortunately I had some major problems while trying to set > up a simple sample application for my tests using Tomcat7 and the > latest OWB release. I had a deeper look at the issues and now want to > share my thoughts on it. > > 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: > > http://pastebin.com/raw.php?i=0rs98g6m > > 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 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. > > What do you think? > > Christian > > > -- > Christian Kaltepoth > Blog: http://chkal.blogspot.com/ > Twitter: http://twitter.com/chkal >
