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
>

Reply via email to