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

Reply via email to