Re: [weld-dev] Specializes bean in war causes unsatisfied resolution exception

2016-12-01 Thread Mark Struberg 
I have to correct a few things:

a.) This whole scenario is NOT defined in the CDI specification
b.) This scenario in question is defined by the EE umbrella specification
c.) The behaviour of OWB/TomEE is perfectly fine from an EE umbrella perspective
d.) It also absolutely makes sense
e.) See CDI-129. You did blow a whole into Weld a long time ago, now you have 
to live with it. Otoh that doesn't render the structure and behaviour of EARs 
useless...
f.) OWB doesn't have this problem as the proxy will resolve the correct 
instance for each request. A request to any of the other WARs will use the 
original bean, while a request to the 'special' WAR will use the @Specializes 
class. This is imo also what makes the most sense for users. 
g.) Weld behaviour renders EARs dead and useless. We could go on and remove 
them from the EE specs at all in that case... 
h.) And then I wonder why we have Enterprise EE Servers at all if not even EARs 
work... 
i.) I suggest to seek clarification from Linda and Bill resp the EE umbrella EG.

LieGrue,
strub

> Am 01.12.2016 um 08:57 schrieb Martin Kouba :
> 
> Dne 30.11.2016 v 18:01 Benjamin Confino napsal(a):
>> Thank you for the prompt replies.
>> 
>> In answer to your question. It is UiSnapshotData which gets injected
>> under OWB.
> 
> Ok, thanks. From my point of view this violates the EE class loading rules.
> 
>> 
>> Regards
>> Benjamin
>> 
>> 
>> 
>> From:Martin Kouba 
>> To:Matej Novotny , Benjamin
>> Confino/UK/IBM@IBMGB,
>> Cc:Emily Jiang/UK/IBM@IBMGB, Tom Evans/UK/IBM@IBMGB,
>> weld-dev@lists.jboss.org
>> Date:29/11/2016 07:42
>> Subject:Re: [weld-dev] Specializes bean in war causes
>> unsatisfied resolution exception
>> 
>> 
>> 
>> 
>> Matej is correct. The specializing bean from the war disables the
>> specialized bean from ear/lib. And since the bean from war is not
>> visible to the bean from ear/lib (KinderzuschussKinderServiceImpl) an
>> unsatisfied dependency exists.
>> 
>> By the way, what instance of SnapshotData gets injected into
>> KinderzuschussKinderServiceImpl for OWB? Is it UiSnapshotData from the
>> war/lib?
>> 
>> Martin
>> 
>> Dne 29.11.2016 v 07:06 Matej Novotny napsal(a):
>>> Hello Benjamin
>>> 
>>> Thanks for well written question!
>>> 
 (You can see the application at was_bugs/was_bug22 at master ·
 thikade/was_bugs · GitHub )
>>> 
>>> Thanks! Took a glance and it looks like the infamous EAR visibility issue.
>>> 
 My first thought was that this application should not work
>>> 
>>> I agree with that. Anything located in EAR/lib cannot really "see"
>> into WAR.
>>> Hence the bean with @Specializes (in WAR) will disable the original
>> bean (in EAR/lib) and the injection cannot be performed as
>>> the specialized bean is not visible to the archive in EAR/lib.
>>> 
 I confirmed that this application works fine on OpenWebBeans.
>>> 
>>> The fact that it does NOT work should be in accord with Java EE spec
>> and its visibility restrictions.
>>> Maybe you should be asking OWB guys why does it work at all?
>>> 
>>> I am no EAR expert but I really think this is Java EE spec (not CDI)
>> intended behavior.
>>> 
>>> Matej
>>> 
>>> - Original Message -
 From: "Benjamin Confino" 
 To: weld-dev@lists.jboss.org
 Cc: "Tom Evans" , "Emily Jiang" 
 Sent: Monday, November 28, 2016 4:56:12 PM
 Subject: [weld-dev] Specializes bean in war causes unsatisfied
>> resolution exception
 
 Hello
 
 A customer of mine sent in a test application with the following
>> structure:
 
 A war file inside ear
 Two jar files inside ear/lib
 One jar file inside ear/war/WEB-INF/lib
 
 There is a class inside one of the ear/lib jar files which @Injects a
>> bean
 from the other ear/lib jar file
 
 And there is a class inside the ear/war/WEB-INF/lib jar file that
 @Specializes the bean inside an ear/lib jar file
 
 (You can see the application at was_bugs/was_bug22 at master ·
 thikade/was_bugs · GitHub )
 
 Attempting to run this application on Weld results in an Unsatisfied
 Resolution Exception. When I remove the jar containing the
>> @Specializes bean
 the application works correctly.
 
 
 My first thought was that this application should not work, because
>> the war
 file and it's internal jar would have a second classloader that would be
 invisible to the application classloader. However the customer
>> attested, and
 I confirmed that this application works fine on OpenWebBeans.
 
 I do not think this is an integration issue, because I tested this on
>> Wildfly
 and got the same error.
 
 
 So it seems that Weld throws an Unsatisfied Resolution Exception

Re: [weld-dev] Specializes bean in war causes unsatisfied resolution exception

2016-12-01 Thread Martin Kouba 
Dne 30.11.2016 v 18:01 Benjamin Confino napsal(a):
> Thank you for the prompt replies.
>
> In answer to your question. It is UiSnapshotData which gets injected
> under OWB.

Ok, thanks. From my point of view this violates the EE class loading rules.

>
> Regards
> Benjamin
>
>
>
> From:Martin Kouba 
> To:Matej Novotny , Benjamin
> Confino/UK/IBM@IBMGB,
> Cc:Emily Jiang/UK/IBM@IBMGB, Tom Evans/UK/IBM@IBMGB,
> weld-dev@lists.jboss.org
> Date:29/11/2016 07:42
> Subject:Re: [weld-dev] Specializes bean in war causes
> unsatisfied resolution exception
> 
>
>
>
> Matej is correct. The specializing bean from the war disables the
> specialized bean from ear/lib. And since the bean from war is not
> visible to the bean from ear/lib (KinderzuschussKinderServiceImpl) an
> unsatisfied dependency exists.
>
> By the way, what instance of SnapshotData gets injected into
> KinderzuschussKinderServiceImpl for OWB? Is it UiSnapshotData from the
> war/lib?
>
> Martin
>
> Dne 29.11.2016 v 07:06 Matej Novotny napsal(a):
>> Hello Benjamin
>>
>> Thanks for well written question!
>>
>>> (You can see the application at was_bugs/was_bug22 at master ·
>>> thikade/was_bugs · GitHub )
>>
>> Thanks! Took a glance and it looks like the infamous EAR visibility issue.
>>
>>> My first thought was that this application should not work
>>
>> I agree with that. Anything located in EAR/lib cannot really "see"
> into WAR.
>> Hence the bean with @Specializes (in WAR) will disable the original
> bean (in EAR/lib) and the injection cannot be performed as
>> the specialized bean is not visible to the archive in EAR/lib.
>>
>>> I confirmed that this application works fine on OpenWebBeans.
>>
>> The fact that it does NOT work should be in accord with Java EE spec
> and its visibility restrictions.
>> Maybe you should be asking OWB guys why does it work at all?
>>
>> I am no EAR expert but I really think this is Java EE spec (not CDI)
> intended behavior.
>>
>> Matej
>>
>> - Original Message -
>>> From: "Benjamin Confino" 
>>> To: weld-dev@lists.jboss.org
>>> Cc: "Tom Evans" , "Emily Jiang" 
>>> Sent: Monday, November 28, 2016 4:56:12 PM
>>> Subject: [weld-dev] Specializes bean in war causes unsatisfied
> resolution exception
>>>
>>> Hello
>>>
>>> A customer of mine sent in a test application with the following
> structure:
>>>
>>> A war file inside ear
>>> Two jar files inside ear/lib
>>> One jar file inside ear/war/WEB-INF/lib
>>>
>>> There is a class inside one of the ear/lib jar files which @Injects a
> bean
>>> from the other ear/lib jar file
>>>
>>> And there is a class inside the ear/war/WEB-INF/lib jar file that
>>> @Specializes the bean inside an ear/lib jar file
>>>
>>> (You can see the application at was_bugs/was_bug22 at master ·
>>> thikade/was_bugs · GitHub )
>>>
>>> Attempting to run this application on Weld results in an Unsatisfied
>>> Resolution Exception. When I remove the jar containing the
> @Specializes bean
>>> the application works correctly.
>>>
>>>
>>> My first thought was that this application should not work, because
> the war
>>> file and it's internal jar would have a second classloader that would be
>>> invisible to the application classloader. However the customer
> attested, and
>>> I confirmed that this application works fine on OpenWebBeans.
>>>
>>> I do not think this is an integration issue, because I tested this on
> Wildfly
>>> and got the same error.
>>>
>>>
>>> So it seems that Weld throws an Unsatisfied Resolution Exception if
>>> @specializes exists in a class that is loaded by a classloader which
> is not
>>> visible .
>>>
>>> What do you think is the correct behaviour is in this instance? From a
>>> classloading perspective a class inside ear/lib should not be able to
> see a
>>> class inside ear/war; but on the other hand the entire purpose of a
>>> @Specializes bean is that you drop it into your application and it
> replaces
>>> the original bean. It feels appropriate that you can drop in a war file
>>> containing the @Specializes bean and it just works without you having
> to do
>>> anything extra.
>>>
>>> Best regards
>>> Benjamin
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with number
>>> 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>>>
>>> ___
>>> weld-dev mailing list
>>> weld-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>> ___
>> weld-dev mailing list
>> weld-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
>