Hey Mark, sure, this would be a very nice solution for the problem. Unfortunately I don't know how Weld solves this issue. I'll try to have a look if find some time.
I've built a simple sample application to reproduce this. Should I open a ticket and attach it? Christian 2011/11/16 Mark Struberg <[email protected]>: > Guess I need to think a bit longer about this. > But the solution could be to Ignore it on startup and store the 'classFailed' > somewhere. And once it is being used at an InjectionPoint, then we throw out > the Exception... Would be nice of course if this information could be in > AnnotatedType (which it currently isn't). We need to think about this. I'm > not even sure if we could create an AnnotatedType at all, because there is > just no way to create a Class which you can store into them (without breaking > some JVMs). > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Christian Kaltepoth <[email protected]> >> To: [email protected] >> Cc: >> Sent: Wednesday, November 16, 2011 10:25 AM >> Subject: Re: NoClassDefFoundError for optional dependencies >> >> 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 >> > -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
