Hi Mark, thanks for your quick response. :)
Yes, I know that there are attempts to add something like @Optional or @Requires to the spec. And I definitely think that makes sense. However 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). Wouldn't it be possible to simply ignore such classes that cannot be loaded? If a class is missing that is mandatory for the application to run the deployment will surely fail later on. But I don't think OWB should completely abort in such a situation during startup. Thanks for sharing you thoughts on this! :) Christian 2011/11/16 Mark Struberg <[email protected]>: > 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 >> > -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
