4:56 p.m.
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
7:06 a.m.
New subject: Specializes bean in war causes unsatisfied resolution exception
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" <BENJAMIC(a)uk.ibm.com>
> To: weld-dev(a)lists.jboss.org
> Cc: "Tom Evans" <TEVANS(a)uk.ibm.com>, "Emily Jiang"
<EMIJIANG(a)uk.ibm.com>
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
8:42 a.m.
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" <BENJAMIC(a)uk.ibm.com>
> To: weld-dev(a)lists.jboss.org
> Cc: "Tom Evans" <TEVANS(a)uk.ibm.com>, "Emily Jiang"
<EMIJIANG(a)uk.ibm.com>
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
6:01 p.m.
Thank you for the prompt replies.
In answer to your question. It is UiSnapshotData which gets injected under
OWB.
Regards
Benjamin
From: Martin Kouba <mkouba(a)redhat.com>
To: Matej Novotny <manovotn(a)redhat.com>, Benjamin
Confino/UK/IBM@IBMGB,
Cc: Emily Jiang/UK/IBM@IBMGB, Tom Evans/UK/IBM@IBMGB,
weld-dev(a)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" <BENJAMIC(a)uk.ibm.com>
> To: weld-dev(a)lists.jboss.org
> Cc: "Tom Evans" <TEVANS(a)uk.ibm.com>, "Emily Jiang"
<EMIJIANG(a)uk.ibm.com>
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
_______________________________________________
weld-dev mailing list
weld-dev(a)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
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
8:57 a.m.
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 <mkouba(a)redhat.com>
To: Matej Novotny <manovotn(a)redhat.com>, Benjamin
Confino/UK/IBM@IBMGB,
Cc: Emily Jiang/UK/IBM@IBMGB, Tom Evans/UK/IBM@IBMGB,
weld-dev(a)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" <BENJAMIC(a)uk.ibm.com>
>> To: weld-dev(a)lists.jboss.org
>> Cc: "Tom Evans" <TEVANS(a)uk.ibm.com>, "Emily Jiang"
<EMIJIANG(a)uk.ibm.com>
>> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)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
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
1:23 p.m.
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
<mkouba(a)redhat.com>:
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 <mkouba(a)redhat.com>
> To: Matej Novotny <manovotn(a)redhat.com>, Benjamin
> Confino/UK/IBM@IBMGB,
> Cc: Emily Jiang/UK/IBM@IBMGB, Tom Evans/UK/IBM@IBMGB,
> weld-dev(a)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" <BENJAMIC(a)uk.ibm.com>
>>> To: weld-dev(a)lists.jboss.org
>>> Cc: "Tom Evans" <TEVANS(a)uk.ibm.com>, "Emily Jiang"
<EMIJIANG(a)uk.ibm.com>
>>> 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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev(a)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
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
2696
days inactive
2699
days old
5 comments
4 participants
participants (4)
-
Benjamin Confino -
Mark Struberg -
Martin Kouba -
Matej Novotny