Thanks Christian! We should solve this somehow, but in your case I think it would be much cleaner to move all the Hibernate specific stuff to Hibernate itself and just use @Specializes to enable these code parts automatically. We've done this in CODI for quite a few things. CODI itself is purely compiled against javax.* APIs, but we have 'CODI extensions' on apache-extras which just use @Specializes or @Alternative to enhance the default features with implementation specific hacks. Wdyt?
Seam-persistence should really work the same with all JPA providers. Otherwise it will also be hard from an interop pov. People will switch the Server and their code would fundamentally change... LieGrue, strub ----- Original Message ----- > From: Christian Kaltepoth <[email protected]> > To: [email protected] > Cc: > Sent: Thursday, November 17, 2011 3:42 PM > Subject: Re: NoClassDefFoundError for optional dependencies > > Hey Mark, > > sorry for my late reply. There was so much stuff for me to do in the > office after I returned from W-JAX! :) > > I just created the JIRA ticket: > > https://issues.apache.org/jira/browse/OWB-629 > > I'll try to find some time at the weekend to have a deeper look at > this issue. Feel free to contact me at any time if you have any > questions regarding this issue or my sample application. > > Thank you very much > > Christian > > > 2011/11/16 Mark Struberg <[email protected]>: >> Yes please, that would really be helpful! >> >> txs and LieGrue, >> strub >> >> >> >> ----- Original Message ----- >>> From: Christian Kaltepoth <[email protected]> >>> To: [email protected] >>> Cc: >>> Sent: Wednesday, November 16, 2011 12:31 PM >>> Subject: Re: NoClassDefFoundError for optional dependencies >>> >>> 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 >>> >> > > > > -- > Christian Kaltepoth > Blog: http://chkal.blogspot.com/ > Twitter: http://twitter.com/chkal >
