From asd at redhat.com  Tue May  9 05:17:22 2017
From: asd at redhat.com (Antoine Sabot-Durand)
Date: Tue, 9 May 2017 11:17:22 +0200
Subject: [cdi-dev] CDI 2.0 passed the final approval ballot
Message-ID: <247793b9-812b-4ed9-a3ad-f7f6abf3609b@Spark>

Hi all,

In case you missed it, CDI 2.0 is now approved:

https://jcp.org/en/jsr/results?id=5995

Thanks again for the great team work and hopping see you around for the next MR or JSR.

Antoine

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170509/a6000397/attachment-0001.html 

From john.ament at spartasystems.com  Tue May  9 07:57:03 2017
From: john.ament at spartasystems.com (John Ament)
Date: Tue, 9 May 2017 11:57:03 +0000
Subject: [cdi-dev] CDI 2.0 passed the final approval ballot
In-Reply-To: <247793b9-812b-4ed9-a3ad-f7f6abf3609b@Spark>
References: <247793b9-812b-4ed9-a3ad-f7f6abf3609b@Spark>
Message-ID: <CY4PR04MB04863F1EAB89EB22DEC4C56298EF0@CY4PR04MB0486.namprd04.prod.outlook.com>

This is great news!  Awesome work everyone, and hopefully this means the RI will reach final within a few days!


John D. Ament
Cloud Software Architect

Sparta Systems

p. 609.807.5466 | m. 609.553.6130

john.ament at spartasystems.com<mailto:john.ament at spartasystems.com> | www.spartasystems.com<http://www.spartasystems.com><http://www.spartasystems.com/>




________________________________
From: cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org> on behalf of Antoine Sabot-Durand <asd at redhat.com>
Sent: Tuesday, May 9, 2017 5:17 AM
To: CDI Java EE Specification
Subject: [cdi-dev] CDI 2.0 passed the final approval ballot

Hi all,

In case you missed it, CDI 2.0 is now approved:

https://jcp.org/en/jsr/results?id=5995

Thanks again for the great team work and hopping see you around for the next MR or JSR.

Antoine

________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170509/3e31c655/attachment.html 

From christian at kaltepoth.de  Tue May  9 14:04:38 2017
From: christian at kaltepoth.de (Christian Kaltepoth)
Date: Tue, 9 May 2017 20:04:38 +0200
Subject: [cdi-dev] CDI 2.0 passed the final approval ballot
In-Reply-To: <CY4PR04MB04863F1EAB89EB22DEC4C56298EF0@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <247793b9-812b-4ed9-a3ad-f7f6abf3609b@Spark>
	<CY4PR04MB04863F1EAB89EB22DEC4C56298EF0@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <CAEXeC6yx9nORD-jYSdpKewiUvnRNo5_THaY=OTYa0XZYpMWG-A@mail.gmail.com>

Congratulations everyone! Great work! :-)

2017-05-09 13:57 GMT+02:00 John Ament <john.ament at spartasystems.com>:

> This is great news!  Awesome work everyone, and hopefully this means the
> RI will reach final within a few days!
>
>
> John D. Ament
> Cloud Software Architect
>
> Sparta Systems
>
> p. 609.807.5466 | m. 609.553.6130
>
> john.ament at spartasystems.com | www.spartasystems.com
> <http://www.spartasystems.com/>
>
>
>
>
> ------------------------------
> *From:* cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org>
> on behalf of Antoine Sabot-Durand <asd at redhat.com>
> *Sent:* Tuesday, May 9, 2017 5:17 AM
> *To:* CDI Java EE Specification
> *Subject:* [cdi-dev] CDI 2.0 passed the final approval ballot
>
> Hi all,
>
> In case you missed it, CDI 2.0 is now approved:
>
> https://jcp.org/en/jsr/results?id=5995
>
> Thanks again for the great team work and hopping see you around for the
> next MR or JSR.
>
> Antoine
>
> ------------------------------
> NOTICE: This e-mail message and any attachments may contain confidential,
> proprietary, and/or privileged information which should be treated
> accordingly. If you are not the intended recipient, please notify the
> sender immediately by return e-mail, delete this message, and destroy all
> physical and electronic copies. Thank you.
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>



-- 
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170509/ceb8d186/attachment.html 

From rmannibucau at gmail.com  Tue May  9 16:17:35 2017
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 9 May 2017 22:17:35 +0200
Subject: [cdi-dev] CDI 2.0 passed the final approval ballot
In-Reply-To: <CAEXeC6yx9nORD-jYSdpKewiUvnRNo5_THaY=OTYa0XZYpMWG-A@mail.gmail.com>
References: <247793b9-812b-4ed9-a3ad-f7f6abf3609b@Spark>
	<CY4PR04MB04863F1EAB89EB22DEC4C56298EF0@CY4PR04MB0486.namprd04.prod.outlook.com>
	<CAEXeC6yx9nORD-jYSdpKewiUvnRNo5_THaY=OTYa0XZYpMWG-A@mail.gmail.com>
Message-ID: <CACLE=7PDA8utSk8iRLgC2OsUB9j41h+5+svrWXNeFW4puQ1DBw@mail.gmail.com>

Congrats guys!


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-05-09 20:04 GMT+02:00 Christian Kaltepoth <christian at kaltepoth.de>:

> Congratulations everyone! Great work! :-)
>
> 2017-05-09 13:57 GMT+02:00 John Ament <john.ament at spartasystems.com>:
>
>> This is great news!  Awesome work everyone, and hopefully this means the
>> RI will reach final within a few days!
>>
>>
>> John D. Ament
>> Cloud Software Architect
>>
>> Sparta Systems
>>
>> p. 609.807.5466 | m. 609.553.6130
>>
>> john.ament at spartasystems.com | www.spartasystems.com
>> <http://www.spartasystems.com/>
>>
>>
>>
>>
>> ------------------------------
>> *From:* cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org>
>> on behalf of Antoine Sabot-Durand <asd at redhat.com>
>> *Sent:* Tuesday, May 9, 2017 5:17 AM
>> *To:* CDI Java EE Specification
>> *Subject:* [cdi-dev] CDI 2.0 passed the final approval ballot
>>
>> Hi all,
>>
>> In case you missed it, CDI 2.0 is now approved:
>>
>> https://jcp.org/en/jsr/results?id=5995
>>
>> Thanks again for the great team work and hopping see you around for the
>> next MR or JSR.
>>
>> Antoine
>>
>> ------------------------------
>> NOTICE: This e-mail message and any attachments may contain confidential,
>> proprietary, and/or privileged information which should be treated
>> accordingly. If you are not the intended recipient, please notify the
>> sender immediately by return e-mail, delete this message, and destroy all
>> physical and electronic copies. Thank you.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (http://www.apache.org/license
>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
>> provider waives all patent and other intellectual property rights inherent
>> in such information.
>>
>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170509/89f59bc8/attachment-0001.html 

From ljnelson at gmail.com  Tue May  9 16:23:26 2017
From: ljnelson at gmail.com (Laird Nelson)
Date: Tue, 09 May 2017 20:23:26 +0000
Subject: [cdi-dev] CDI 2.0 passed the final approval ballot
In-Reply-To: <247793b9-812b-4ed9-a3ad-f7f6abf3609b@Spark>
References: <247793b9-812b-4ed9-a3ad-f7f6abf3609b@Spark>
Message-ID: <CAHNdxumpj6poampf1AOVqbo7wGdSNOqvC6JCJC48o48kyCmYQw@mail.gmail.com>

On Tue, May 9, 2017 at 3:32 AM Antoine Sabot-Durand <asd at redhat.com> wrote:

> In case you missed it, CDI 2.0 is now approved:
>
> https://jcp.org/en/jsr/results?id=5995
>
> Thanks again for the great team work and hopping see you around for the
> next MR or JSR.
>

Congratulations.  This specification is game-changing IMHO.

Best,
Laird
--
http://about.me/lairdnelson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170509/f8cac2e5/attachment.html 

From asd at redhat.com  Wed May 10 03:39:24 2017
From: asd at redhat.com (Antoine Sabot-Durand)
Date: Wed, 10 May 2017 09:39:24 +0200
Subject: [cdi-dev] CDI 2.0 hit maven Central
Message-ID: <82e4aaa5-b3ab-4807-9bb9-4005f94162a3@Spark>

Hi all,

CDI 2.0 is now available in maven central:

http://search.maven.org/#artifactdetails|javax.enterprise|cdi-api|2.0|jar

Antoine


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170510/33e916e2/attachment.html 

From builds at travis-ci.org  Wed May 10 04:45:15 2017
From: builds at travis-ci.org (Travis CI)
Date: Wed, 10 May 2017 08:45:15 +0000
Subject: [cdi-dev] Errored: cdi-spec/cdi#366 (master - 5c0ab0d)
In-Reply-To: <cdi-spec/cdi+230668473+errored@travis-ci.org>
Message-ID: <5912d3178638_43fbd816dcae4189778c@79d02ae1-d7d9-4860-94af-9d4438683af9.mail>

Build Update for cdi-spec/cdi
-------------------------------------

Build: #366
Status: Errored

Duration: 4 minutes and 20 seconds
Commit: 5c0ab0d (master)
Author: Antoine Sabot-Durand
Message: Prepare for development of 2.0-SNAPSHOT

View the changeset: https://github.com/cdi-spec/cdi/compare/c95203716d8c...5c0ab0d365e8

View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/230668473?utm_source=email&utm_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170510/5e6ae5d0/attachment.html 

From builds at travis-ci.org  Wed May 10 05:34:14 2017
From: builds at travis-ci.org (Travis CI)
Date: Wed, 10 May 2017 09:34:14 +0000
Subject: [cdi-dev] Passed: cdi-spec/cdi#367 (master - 3f5e78f)
In-Reply-To: <cdi-spec/cdi+230684546+passed@travis-ci.org>
Message-ID: <5912deb791460_43fbd815d97501970117@79d02ae1-d7d9-4860-94af-9d4438683af9.mail>

Build Update for cdi-spec/cdi
-------------------------------------

Build: #367
Status: Passed

Duration: 3 minutes and 35 seconds
Commit: 3f5e78f (master)
Author: Antoine Sabot-Durand
Message: Prepare for development of 2.1-SNAPSHOT

View the changeset: https://github.com/cdi-spec/cdi/compare/5c0ab0d365e8...3f5e78f927e5

View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/230684546?utm_source=email&utm_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170510/40a7e1d2/attachment-0001.html 

From ljnelson at gmail.com  Thu May 11 15:30:17 2017
From: ljnelson at gmail.com (Laird Nelson)
Date: Thu, 11 May 2017 19:30:17 +0000
Subject: [cdi-dev] What, if any,
 guarantees are made about invoking asynchronous event observer
 methods?
Message-ID: <CAHNdxu=JCut+NmMHiTSPaNxs6n2c54ASRbN6A8Rx4EfpEr=a_A@mail.gmail.com>

I'm using CDI 2.0 and Weld 3.0.0.CR2 in "SE mode".

If I fire an asynchronous event without any special notification options,
my understanding is that the container will arrange for that event to be
delivered to asynchronous observers.

Is (appropriate) asynchronous observer method invocation guaranteed to
happen at some point?  Section 10.2.2 seems to hint that it is:

"Event fired [sic] with the fireAsync() method is [sic] fired
asynchronously. *All the resolved asynchronous observers* (as defined in
Observer resolution) *are called* in one or more different threads."

To me, this says that if I use fireAsync() to fire an event, then if I have
a (resolved) asynchronous observer method for it it will be notified before
the container closes no matter what.

(I believe I am observing a race condition somewhere in here that might
show that Weld's default asynchronous event delivery machinery does not
actually get around to delivering the event I've queued up before the
container closes.  Sometimes the event is received, sometimes it is not.
Obviously if there is no such guarantee this could be permitted behavior.)

Best,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170511/90fcb120/attachment.html 

From manovotn at redhat.com  Fri May 12 02:19:51 2017
From: manovotn at redhat.com (Matej Novotny)
Date: Fri, 12 May 2017 02:19:51 -0400 (EDT)
Subject: [cdi-dev] What, if any,
 guarantees are made about invoking asynchronous event observer
 methods?
In-Reply-To: <CAHNdxu=JCut+NmMHiTSPaNxs6n2c54ASRbN6A8Rx4EfpEr=a_A@mail.gmail.com>
References: <CAHNdxu=JCut+NmMHiTSPaNxs6n2c54ASRbN6A8Rx4EfpEr=a_A@mail.gmail.com>
Message-ID: <1144041245.7137007.1494569991649.JavaMail.zimbra@redhat.com>

Hi Laird, 

if I understand you correctly, there is no guarantee for that in Weld. If you fire an async event it will spin another thread (or more), where it will start notifying async observers.
Only after it is done, it will come back to the main thread with result. There is no synchronization around this - that would kind of go against the nature of truly asynchronous calls, wouldn't it?

As for spec interpretation, I don't think the implication you suggest is intended there.
It's a shame we haven't clarified this earlier though.

What exactly is your use case?

Matej


----- Original Message -----
> From: "Laird Nelson" <ljnelson at gmail.com>
> To: "cdi-dev" <cdi-dev at lists.jboss.org>
> Sent: Thursday, May 11, 2017 9:30:17 PM
> Subject: [cdi-dev] What, if any, guarantees are made about invoking asynchronous event observer methods?
> 
> I'm using CDI 2.0 and Weld 3.0.0.CR2 in "SE mode".
> 
> If I fire an asynchronous event without any special notification options, my
> understanding is that the container will arrange for that event to be
> delivered to asynchronous observers.
> 
> Is (appropriate) asynchronous observer method invocation guaranteed to happen
> at some point? Section 10.2.2 seems to hint that it is:
> 
> "Event fired [sic] with the fireAsync() method is [sic] fired asynchronously.
> All the resolved asynchronous observers (as defined in Observer resolution)
> are called in one or more different threads."
> 
> To me, this says that if I use fireAsync() to fire an event, then if I have a
> (resolved) asynchronous observer method for it it will be notified before
> the container closes no matter what.
> 
> (I believe I am observing a race condition somewhere in here that might show
> that Weld's default asynchronous event delivery machinery does not actually
> get around to delivering the event I've queued up before the container
> closes. Sometimes the event is received, sometimes it is not. Obviously if
> there is no such guarantee this could be permitted behavior.)
> 
> Best,
> Laird
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.

From mkouba at redhat.com  Fri May 12 02:39:49 2017
From: mkouba at redhat.com (Martin Kouba)
Date: Fri, 12 May 2017 08:39:49 +0200
Subject: [cdi-dev] What, if any,
 guarantees are made about invoking asynchronous event observer
 methods?
In-Reply-To: <CAHNdxu=JCut+NmMHiTSPaNxs6n2c54ASRbN6A8Rx4EfpEr=a_A@mail.gmail.com>
References: <CAHNdxu=JCut+NmMHiTSPaNxs6n2c54ASRbN6A8Rx4EfpEr=a_A@mail.gmail.com>
Message-ID: <4536e0da-ad52-0518-caa4-26cae2856fd4@redhat.com>

Dne 11.5.2017 v 21:30 Laird Nelson napsal(a):
> I'm using CDI 2.0 and Weld 3.0.0.CR2 in "SE mode".
>
> If I fire an asynchronous event without any special notification
> options, my understanding is that the container will arrange for that
> event to be delivered to asynchronous observers.
>
> Is (appropriate) asynchronous observer method invocation guaranteed to
> happen at some point?  Section 10.2.2 seems to hint that it is:
>
> "Event fired [sic] with the fireAsync() method is [sic] fired
> asynchronously. *All the resolved asynchronous observers* (as defined in
> Observer resolution) *are called* in one or more different threads."
>
> To me, this says that if I use fireAsync() to fire an event, then if I
> have a (resolved) asynchronous observer method for it it will be
> notified before the container closes no matter what.

I think it's undefined. And I don't believe it would be reasonable to 
block the container shutdown because of an async observer method waiting 
for notification. The spec is clear that the container must destroy all 
contexts when an application is stopped. And if we destroy the contexts 
then the bean declaring the observer or its dependencies might be in 
inconsistent state.

>
> (I believe I am observing a race condition somewhere in here that might
> show that Weld's default asynchronous event delivery machinery does not
> actually get around to delivering the event I've queued up before the
> container closes.  Sometimes the event is received, sometimes it is
> not.  Obviously if there is no such guarantee this could be permitted
> behavior.)
>
> Best,
> Laird
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From mkouba at redhat.com  Fri May 12 03:57:43 2017
From: mkouba at redhat.com (Martin Kouba)
Date: Fri, 12 May 2017 09:57:43 +0200
Subject: [cdi-dev] What, if any,
 guarantees are made about invoking asynchronous event observer
 methods?
In-Reply-To: <4536e0da-ad52-0518-caa4-26cae2856fd4@redhat.com>
References: <CAHNdxu=JCut+NmMHiTSPaNxs6n2c54ASRbN6A8Rx4EfpEr=a_A@mail.gmail.com>
	<4536e0da-ad52-0518-caa4-26cae2856fd4@redhat.com>
Message-ID: <e5cab5e5-1203-fec8-3c2c-95c847b8b278@redhat.com>

FYI there is already https://issues.jboss.org/browse/CDI-570 which seems 
to be related.

Martin

Dne 12.5.2017 v 08:39 Martin Kouba napsal(a):
> Dne 11.5.2017 v 21:30 Laird Nelson napsal(a):
>> I'm using CDI 2.0 and Weld 3.0.0.CR2 in "SE mode".
>>
>> If I fire an asynchronous event without any special notification
>> options, my understanding is that the container will arrange for that
>> event to be delivered to asynchronous observers.
>>
>> Is (appropriate) asynchronous observer method invocation guaranteed to
>> happen at some point?  Section 10.2.2 seems to hint that it is:
>>
>> "Event fired [sic] with the fireAsync() method is [sic] fired
>> asynchronously. *All the resolved asynchronous observers* (as defined in
>> Observer resolution) *are called* in one or more different threads."
>>
>> To me, this says that if I use fireAsync() to fire an event, then if I
>> have a (resolved) asynchronous observer method for it it will be
>> notified before the container closes no matter what.
>
> I think it's undefined. And I don't believe it would be reasonable to
> block the container shutdown because of an async observer method waiting
> for notification. The spec is clear that the container must destroy all
> contexts when an application is stopped. And if we destroy the contexts
> then the bean declaring the observer or its dependencies might be in
> inconsistent state.
>
>>
>> (I believe I am observing a race condition somewhere in here that might
>> show that Weld's default asynchronous event delivery machinery does not
>> actually get around to delivering the event I've queued up before the
>> container closes.  Sometimes the event is received, sometimes it is
>> not.  Obviously if there is no such guarantee this could be permitted
>> behavior.)
>>
>> Best,
>> Laird
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses
>> the code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From ljnelson at gmail.com  Fri May 12 13:08:43 2017
From: ljnelson at gmail.com (Laird Nelson)
Date: Fri, 12 May 2017 17:08:43 +0000
Subject: [cdi-dev] What, if any,
 guarantees are made about invoking asynchronous event observer
 methods?
In-Reply-To: <1144041245.7137007.1494569991649.JavaMail.zimbra@redhat.com>
References: <CAHNdxu=JCut+NmMHiTSPaNxs6n2c54ASRbN6A8Rx4EfpEr=a_A@mail.gmail.com>
	<1144041245.7137007.1494569991649.JavaMail.zimbra@redhat.com>
Message-ID: <CAHNdxumDNYdwLr0WxG2W2XvH0EDLrZFeBNhnhr0ihRbPMUwk8A@mail.gmail.com>

On Thu, May 11, 2017 at 11:19 PM Matej Novotny <manovotn at redhat.com> wrote:

> if I understand you correctly, there is no guarantee for that in Weld.


OK thanks.


> If you fire an async event it will spin another thread (or more), where it
> will start notifying async observers.
>

Sure.  My question is: is there any guarantee that the asynchronous
observer method will be *called* at all, regardless of whether it
finishes?  I believe the answer is no.  That is, there are absolutely no
semantics guaranteed about delivery (neither at-least-once nor at-most-once
nor exactly-once).

So I've learned that in an SE setting anyway it is important to know
that?depending on when the SeContainer is closed, obviously?some of your
asynchronous observers may never be notified.  Additionally it is important
to know that calling thenRun()
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html#thenRun-java.lang.Runnable->
(or other variants not ending in "Async") on the returned CompletionStage
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html>
may very well not work, and its exceptionally()
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html#exceptionally-java.util.function.Function->
stuff may also never be called.


> Only after it is done, it will come back to the main thread with result.
> There is no synchronization around this - that would kind of go against the
> nature of truly asynchronous calls, wouldn't it?
>

I understand that the container won't block waiting for the asynchronous
method to *come back*.  As you say, that wouldn't be asynchronous (although
you could make an argument that everything should be gathered up before the
container closes, but I understand that's contentious and has a lot of
overhead).

But I *am* interested in: is there any guarantee that the asynchronous
observer method will be *called*?  The answer appears to be no.  (Another
way to look at it is my questions are around the behavior of the returned
CompletionStage
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html>
.)

Martin referred me to https://issues.jboss.org/browse/CDI-570 which is
another variant of my questions.


> What exactly is your use case?
>

Well, now it's just curiosity. :-)  It looks like when SeContainer.close()
is called, everything stops more or less immediately, regardless of what
state anything is in (even if, say, your asynchronous observer has a bean
injected into it that observes the closing of the scope).

Best,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170512/667df85e/attachment.html 

From ljnelson at gmail.com  Fri May 12 13:31:44 2017
From: ljnelson at gmail.com (Laird Nelson)
Date: Fri, 12 May 2017 17:31:44 +0000
Subject: [cdi-dev] What, if any,
 guarantees are made about invoking asynchronous event observer
 methods?
In-Reply-To: <CAHNdxumDNYdwLr0WxG2W2XvH0EDLrZFeBNhnhr0ihRbPMUwk8A@mail.gmail.com>
References: <CAHNdxu=JCut+NmMHiTSPaNxs6n2c54ASRbN6A8Rx4EfpEr=a_A@mail.gmail.com>
	<1144041245.7137007.1494569991649.JavaMail.zimbra@redhat.com>
	<CAHNdxumDNYdwLr0WxG2W2XvH0EDLrZFeBNhnhr0ihRbPMUwk8A@mail.gmail.com>
Message-ID: <CAHNdxu=j9AzbJBX=Y+_PL1+651-zoO=5UWoZYFeVDu3hR8X7Mw@mail.gmail.com>

On Fri, May 12, 2017 at 10:08 AM Laird Nelson <ljnelson at gmail.com> wrote:

> Martin referred me to https://issues.jboss.org/browse/CDI-570 which is
> another variant of my questions.
>

I've put a Github repo up with some explorations that might be fun or
interesting to people: https://github.com/ljnelson/weld-570

Best,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170512/021a253c/attachment-0001.html 

From issues at jboss.org  Fri May 12 14:06:00 2017
From: issues at jboss.org (Laird Nelson (JIRA))
Date: Fri, 12 May 2017 14:06:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-570) Weld shutdown in Java SE during
 asynch event calling
In-Reply-To: <JIRA.12592284.1447184299000@Atlassian.JIRA>
References: <JIRA.12592284.1447184299000@Atlassian.JIRA>
	<JIRA.12592284.1447184299000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12592284.1447184299000.114901.1494612360189@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405849#comment-13405849 ] 

Laird Nelson commented on CDI-570:
----------------------------------

In case it is helpful: I put a [Github repository|https://github.com/ljnelson/weld-570] up that putters around with aspects related to this issue if anyone is interested.

> Weld shutdown in Java SE during asynch event calling
> ----------------------------------------------------
>
>                 Key: CDI-570
>                 URL: https://issues.jboss.org/browse/CDI-570
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Michael Remijan
>
> In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down.  My assumption is the JVM should wait until all the async observers are complete before shutting down.  Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From manovotn at redhat.com  Mon May 15 03:13:22 2017
From: manovotn at redhat.com (Matej Novotny)
Date: Mon, 15 May 2017 03:13:22 -0400 (EDT)
Subject: [cdi-dev] What, if any,
 guarantees are made about invoking asynchronous event observer
 methods?
In-Reply-To: <CAHNdxu=j9AzbJBX=Y+_PL1+651-zoO=5UWoZYFeVDu3hR8X7Mw@mail.gmail.com>
References: <CAHNdxu=JCut+NmMHiTSPaNxs6n2c54ASRbN6A8Rx4EfpEr=a_A@mail.gmail.com>
	<1144041245.7137007.1494569991649.JavaMail.zimbra@redhat.com>
	<CAHNdxumDNYdwLr0WxG2W2XvH0EDLrZFeBNhnhr0ihRbPMUwk8A@mail.gmail.com>
	<CAHNdxu=j9AzbJBX=Y+_PL1+651-zoO=5UWoZYFeVDu3hR8X7Mw@mail.gmail.com>
Message-ID: <269237304.7826848.1494832402361.JavaMail.zimbra@redhat.com>

Hi Laird,

Thanks for creating a reproducer straight away.
I took a glance at the repo and here is what I think:

TestScenario1/2 are pretty much what we are discussing here - the container terminates and observers don't get notified any more. 
Obviously, if you hang any additional 'thenRun' etc. on top of that, it won't work either.


TestScenario3 is with Weld parallel mode and is IMO out of scope of previous discussion but important nonetheless.
This is indeed weird and I think you are observing a peculiar behaviour of default executor in SE, which is ForkJoinPool.
We have a test[1] for parallel execution in SE, where we defined your own executor (see 'createWeld' method) and it works like a charm.
I think we need to look into FJP to see what's truly going on there.

Matej

____________________________________________________________________________________________
[1]https://github.com/weld/core/blob/master/environments/se/tests/src/test/java/org/jboss/weld/environment/se/test/event/options/mode/NotificationModeTest.java#L63

----- Original Message -----
> From: "Laird Nelson" <ljnelson at gmail.com>
> To: "cdi-dev" <cdi-dev at lists.jboss.org>, "Matej Novotny" <manovotn at redhat.com>
> Sent: Friday, May 12, 2017 7:31:44 PM
> Subject: Re: [cdi-dev] What, if any, guarantees are made about invoking asynchronous event observer methods?
> 
> On Fri, May 12, 2017 at 10:08 AM Laird Nelson <ljnelson at gmail.com> wrote:
> 
> > Martin referred me to https://issues.jboss.org/browse/CDI-570 which is
> > another variant of my questions.
> >
> 
> I've put a Github repo up with some explorations that might be fun or
> interesting to people: https://github.com/ljnelson/weld-570
> 
> Best,
> Laird
> 

From ljnelson at gmail.com  Mon May 15 11:25:10 2017
From: ljnelson at gmail.com (Laird Nelson)
Date: Mon, 15 May 2017 15:25:10 +0000
Subject: [cdi-dev] What, if any,
 guarantees are made about invoking asynchronous event observer
 methods?
In-Reply-To: <269237304.7826848.1494832402361.JavaMail.zimbra@redhat.com>
References: <CAHNdxu=JCut+NmMHiTSPaNxs6n2c54ASRbN6A8Rx4EfpEr=a_A@mail.gmail.com>
	<1144041245.7137007.1494569991649.JavaMail.zimbra@redhat.com>
	<CAHNdxumDNYdwLr0WxG2W2XvH0EDLrZFeBNhnhr0ihRbPMUwk8A@mail.gmail.com>
	<CAHNdxu=j9AzbJBX=Y+_PL1+651-zoO=5UWoZYFeVDu3hR8X7Mw@mail.gmail.com>
	<269237304.7826848.1494832402361.JavaMail.zimbra@redhat.com>
Message-ID: <CAHNdxukijOTeup9qAnpAsyi5-Tst9FH2myeojjSL6Jrn6Gsqfw@mail.gmail.com>

On Mon, May 15, 2017 at 12:13 AM Matej Novotny <manovotn at redhat.com> wrote:

> TestScenario1/2 are pretty much what we are discussing here - the
> container terminates and observers don't get notified any more.
> Obviously, if you hang any additional 'thenRun' etc. on top of that, it
> won't work either.
>

Right.


> TestScenario3 is with Weld parallel mode and is IMO out of scope of
> previous discussion but important nonetheless.
>

Yeah?this git repo was less a reproducer and more just me playing around.
:-)


> This is indeed weird and I think you are observing a peculiar behaviour of
> default executor in SE, which is ForkJoinPool.
> We have a test[1] for parallel execution in SE, where we defined your own
> executor (see 'createWeld' method) and it works like a charm.
> I think we need to look into FJP to see what's truly going on there.
>

Oh, that is interesting.  OK; thanks.

Best,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170515/0566d36f/attachment.html 

From issues at jboss.org  Fri May 19 06:55:00 2017
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Fri, 19 May 2017 06:55:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can
 see classes they should not be able to
In-Reply-To: <JIRA.12693081.1495191248000@Atlassian.JIRA>
References: <JIRA.12693081.1495191248000@Atlassian.JIRA>
	<JIRA.12693081.1495191248335@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693081.1495191248000.152691.1495191300021@Atlassian.JIRA>

Emily Jiang created CDI-702:
-------------------------------

             Summary: Observers in CDI extensions can see classes they should not be able to
                 Key: CDI-702
                 URL: https://issues.jboss.org/browse/CDI-702
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Portable Extensions
    Affects Versions: 2.0 .Final, 1.1.Final, 1.2.Final
            Reporter: Emily Jiang
            Priority: Critical


We observe a undesired behavior on Weld,  which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.

This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.

We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri May 19 07:00:00 2017
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 19 May 2017 07:00:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can
 see classes they should not be able to
In-Reply-To: <JIRA.12693081.1495191248000@Atlassian.JIRA>
References: <JIRA.12693081.1495191248000@Atlassian.JIRA>
	<JIRA.12693081.1495191248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693081.1495191248000.152729.1495191600637@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408900#comment-13408900 ] 

John Ament commented on CDI-702:
--------------------------------

The description of this issue is unclear.  Are you seeing all events being fired or only certain events?  Where in the archive is the extension registered, a JAR within the EAR's lib folder?  Within the WAR file?  Within a library within the WAR file?

> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
>                 Key: CDI-702
>                 URL: https://issues.jboss.org/browse/CDI-702
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>    Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
>            Reporter: Emily Jiang
>            Priority: Critical
>
> We observe a undesired behavior on Weld,  which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri May 19 07:18:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 19 May 2017 07:18:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can
 see classes they should not be able to
In-Reply-To: <JIRA.12693081.1495191248000@Atlassian.JIRA>
References: <JIRA.12693081.1495191248000@Atlassian.JIRA>
	<JIRA.12693081.1495191248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693081.1495191248000.152806.1495192680337@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408908#comment-13408908 ] 

Martin Kouba commented on CDI-702:
----------------------------------

For the record: the *Observer resolution* section in the CDI spec does not mention "accessibility" or "observability" at all (unlike dependency injection). An event is delivered to an observer method if it belongs to an enabled bean and an event type is assignable. Also accessibility rules do not help e.g. if there is an extension with a similar observer:
{code:java}
void observe(ProcessAnnotatedType<?> event) {
  if (event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
    event.veto();
  }
} 
{code}
It should be able to observe all PAT events for all types in a CDI application (of course, we assume the Weld interpretation of {{@ApplicationScoped}}). That's what CDI spec currently requires.

So this issue is more about defining boundaries for events delivery.

> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
>                 Key: CDI-702
>                 URL: https://issues.jboss.org/browse/CDI-702
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>    Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
>            Reporter: Emily Jiang
>            Priority: Critical
>
> We observe a undesired behavior on Weld,  which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri May 19 07:28:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 19 May 2017 07:28:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can
 see classes they should not be able to
In-Reply-To: <JIRA.12693081.1495191248000@Atlassian.JIRA>
References: <JIRA.12693081.1495191248000@Atlassian.JIRA>
	<JIRA.12693081.1495191248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693081.1495191248000.152931.1495193280285@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408908#comment-13408908 ] 

Martin Kouba edited comment on CDI-702 at 5/19/17 7:27 AM:
-----------------------------------------------------------

For the record: the *Observer resolution* section in the CDI spec does not mention "accessibility" or "observability" at all (unlike dependency injection). An event is delivered to an observer method if it belongs to an enabled bean and an event type is assignable. Also accessibility rules do not help e.g. if there is an extension with a similar observer:
{code:java}
void observe(ProcessAnnotatedType<?> event) {
  if (event.getAnnotatedType().isAnnotationPresent(Named.class)) {
    event.veto();
  }
} 
{code}
It should be able to observe all PAT events for all types in a CDI application (of course, we assume the Weld interpretation of {{@ApplicationScoped}}). That's what CDI spec currently requires.

So this issue is more about defining boundaries for events delivery.


was (Author: mkouba):
For the record: the *Observer resolution* section in the CDI spec does not mention "accessibility" or "observability" at all (unlike dependency injection). An event is delivered to an observer method if it belongs to an enabled bean and an event type is assignable. Also accessibility rules do not help e.g. if there is an extension with a similar observer:
{code:java}
void observe(ProcessAnnotatedType<?> event) {
  if (event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
    event.veto();
  }
} 
{code}
It should be able to observe all PAT events for all types in a CDI application (of course, we assume the Weld interpretation of {{@ApplicationScoped}}). That's what CDI spec currently requires.

So this issue is more about defining boundaries for events delivery.

> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
>                 Key: CDI-702
>                 URL: https://issues.jboss.org/browse/CDI-702
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>    Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
>            Reporter: Emily Jiang
>            Priority: Critical
>
> We observe a undesired behavior on Weld,  which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri May 19 12:48:00 2017
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Fri, 19 May 2017 12:48:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can
 see classes they should not be able to
In-Reply-To: <JIRA.12693081.1495191248000@Atlassian.JIRA>
References: <JIRA.12693081.1495191248000@Atlassian.JIRA>
	<JIRA.12693081.1495191248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693081.1495191248000.155774.1495212480336@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emily Jiang updated CDI-702:
----------------------------
    Description: 
We observe a undesired behavior on Weld,  which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
e.g.

myApp.ear
  lib\myLib.jar (LibExtensionA.class, LibOne.class)
  myWarA.war (WarAExtension.class, myWarAServlet.class)
  myWarB.war (WarBExtension.class, myWarBServlet.class)

In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of 
LibOne, myWarAServlet and myWarBServlet.



This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.

We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.

  was:
We observe a undesired behavior on Weld,  which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.

This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.

We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.



> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
>                 Key: CDI-702
>                 URL: https://issues.jboss.org/browse/CDI-702
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>    Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
>            Reporter: Emily Jiang
>            Priority: Critical
>
> We observe a undesired behavior on Weld,  which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
>   lib\myLib.jar (LibExtensionA.class, LibOne.class)
>   myWarA.war (WarAExtension.class, myWarAServlet.class)
>   myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of 
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri May 19 12:50:00 2017
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Fri, 19 May 2017 12:50:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can
 see classes they should not be able to
In-Reply-To: <JIRA.12693081.1495191248000@Atlassian.JIRA>
References: <JIRA.12693081.1495191248000@Atlassian.JIRA>
	<JIRA.12693081.1495191248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693081.1495191248000.155780.1495212600272@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409189#comment-13409189 ] 

Emily Jiang commented on CDI-702:
---------------------------------

John, I provided an example. Please let me know if you still feel confused.

> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
>                 Key: CDI-702
>                 URL: https://issues.jboss.org/browse/CDI-702
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>    Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
>            Reporter: Emily Jiang
>            Priority: Critical
>
> We observe a undesired behavior on Weld,  which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
>   lib\myLib.jar (LibExtensionA.class, LibOne.class)
>   myWarA.war (WarAExtension.class, myWarAServlet.class)
>   myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of 
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri May 19 12:55:00 2017
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Fri, 19 May 2017 12:55:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can
 see classes they should not be able to
In-Reply-To: <JIRA.12693081.1495191248000@Atlassian.JIRA>
References: <JIRA.12693081.1495191248000@Atlassian.JIRA>
	<JIRA.12693081.1495191248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693081.1495191248000.155791.1495212900446@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409191#comment-13409191 ] 

Emily Jiang commented on CDI-702:
---------------------------------

Here are Martin's and Antoine's comments during our previous discussion:
Martin:

{noformat}
1. I'm not talking about class loading and using classes but observing 
ProcessAnnotatedType event -> any WAR can see PAT type and is able to 
observe it.
2. The CDI spec does not define any visibility boundaries for events 
(unlike for typesafe resolution). See for example CDI-518.

So yes, from EE.8.3.1 Web Container Class Loading Requirements it is 
clear that portable apps must not depend on having access to classes 
from the second WAR.

On the other hand, CDI extensions are defined as application wide 
components which should be imho able to process container lifecycle 
events from all bean archives.

{noformat}

Antoine:
{noformat}
Class loading in Java EE platform is far from being a consensus. Vendors are doing different things here, so definition of class visibility is not universal.
Visibility problem in EAR were never solved in CDI for this reason, see https://issues.jboss.org/browse/CDI-129 to have an history on that.


When we relaunched this discussion during CDI 2.0, conclusion was that we agreed on our disagreement with OWB team and that clarification should be done at Java EE spec level (I let you dig in ML archive to check the discussion we had with Mark Struberg at that time).


Even if CDI spec tries to cover all, there are still small differences between Weld and OWB making the switch from one to the other not transparent every time.
I?m sorry you fall in one of these gap, but that doesn?t make Weld buggy, only put one of this difference into light.


Antoine
{noformat}



> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
>                 Key: CDI-702
>                 URL: https://issues.jboss.org/browse/CDI-702
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>    Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
>            Reporter: Emily Jiang
>            Priority: Critical
>
> We observe a undesired behavior on Weld,  which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
>   lib\myLib.jar (LibExtensionA.class, LibOne.class)
>   myWarA.war (WarAExtension.class, myWarAServlet.class)
>   myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of 
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri May 19 12:57:00 2017
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Fri, 19 May 2017 12:57:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can
 see classes they should not be able to
In-Reply-To: <JIRA.12693081.1495191248000@Atlassian.JIRA>
References: <JIRA.12693081.1495191248000@Atlassian.JIRA>
	<JIRA.12693081.1495191248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693081.1495191248000.155795.1495213020246@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409192#comment-13409192 ] 

Emily Jiang commented on CDI-702:
---------------------------------

My view is that the observable should follow the classloading visibility rules. Why extensions are special? This violent the classloading rules.

> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
>                 Key: CDI-702
>                 URL: https://issues.jboss.org/browse/CDI-702
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>    Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
>            Reporter: Emily Jiang
>            Priority: Critical
>
> We observe a undesired behavior on Weld,  which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
>   lib\myLib.jar (LibExtensionA.class, LibOne.class)
>   myWarA.war (WarAExtension.class, myWarAServlet.class)
>   myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of 
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri May 19 13:18:00 2017
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 19 May 2017 13:18:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can
 see classes they should not be able to
In-Reply-To: <JIRA.12693081.1495191248000@Atlassian.JIRA>
References: <JIRA.12693081.1495191248000@Atlassian.JIRA>
	<JIRA.12693081.1495191248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693081.1495191248000.155846.1495214280140@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409202#comment-13409202 ] 

John Ament commented on CDI-702:
--------------------------------

Thanks Emily, makes it clearer.

I'm not convinced this is a CDI issue.  For EE, we don't really specify the visibility, that's part of the EE umbrella spec.  I actually suspect your app server in this case is defining the classes to look for.

> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
>                 Key: CDI-702
>                 URL: https://issues.jboss.org/browse/CDI-702
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>    Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
>            Reporter: Emily Jiang
>            Priority: Critical
>
> We observe a undesired behavior on Weld,  which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
>   lib\myLib.jar (LibExtensionA.class, LibOne.class)
>   myWarA.war (WarAExtension.class, myWarAServlet.class)
>   myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of 
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon May 22 05:27:00 2017
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Mon, 22 May 2017 05:27:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can
 see classes they should not be able to
In-Reply-To: <JIRA.12693081.1495191248000@Atlassian.JIRA>
References: <JIRA.12693081.1495191248000@Atlassian.JIRA>
	<JIRA.12693081.1495191248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693081.1495191248000.2056.1495445220286@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409781#comment-13409781 ] 

Emily Jiang commented on CDI-702:
---------------------------------

[~meetoblivion] The issue is that the CDI extension does something different from other classes in the ear. e.g.  {{myApp.ear
lib\myLib.jar (LibExtensionA.class, LibOne.class)
myWarA.war (WarAExtension.class, myWarAServlet.class)
myWarB.war (WarBExtension.class, myWarBServlet.class)}}
The myWarAServlet will not be able to see classes in myWarB.war. Why are the CDI extensions special? How come all extension classes can see everything in the ear. Basically, my argument is that CDI extensions should follow the same classloading criteria instead of defining itself visibility rules with even being documented.

> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
>                 Key: CDI-702
>                 URL: https://issues.jboss.org/browse/CDI-702
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>    Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
>            Reporter: Emily Jiang
>            Priority: Critical
>
> We observe a undesired behavior on Weld,  which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
>   lib\myLib.jar (LibExtensionA.class, LibOne.class)
>   myWarA.war (WarAExtension.class, myWarAServlet.class)
>   myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of 
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon May 22 05:28:00 2017
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Mon, 22 May 2017 05:28:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can
 see classes they should not be able to
In-Reply-To: <JIRA.12693081.1495191248000@Atlassian.JIRA>
References: <JIRA.12693081.1495191248000@Atlassian.JIRA>
	<JIRA.12693081.1495191248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693081.1495191248000.2064.1495445280477@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409781#comment-13409781 ] 

Emily Jiang edited comment on CDI-702 at 5/22/17 5:27 AM:
----------------------------------------------------------

[~meetoblivion] The issue is that the CDI extension does something different from other classes in the ear. e.g.  

{noformat}
myApp.ear
lib\myLib.jar (LibExtensionA.class, LibOne.class)
myWarA.war (WarAExtension.class, myWarAServlet.class)
myWarB.war (WarBExtension.class, myWarBServlet.class)
{noformat}


The myWarAServlet will not be able to see classes in myWarB.war. Why are the CDI extensions special? How come all extension classes can see everything in the ear. Basically, my argument is that CDI extensions should follow the same classloading criteria instead of defining itself visibility rules with even being documented.


was (Author: emilyj):
[~meetoblivion] The issue is that the CDI extension does something different from other classes in the ear. e.g.  {{myApp.ear
lib\myLib.jar (LibExtensionA.class, LibOne.class)
myWarA.war (WarAExtension.class, myWarAServlet.class)
myWarB.war (WarBExtension.class, myWarBServlet.class)}}
The myWarAServlet will not be able to see classes in myWarB.war. Why are the CDI extensions special? How come all extension classes can see everything in the ear. Basically, my argument is that CDI extensions should follow the same classloading criteria instead of defining itself visibility rules with even being documented.

> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
>                 Key: CDI-702
>                 URL: https://issues.jboss.org/browse/CDI-702
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>    Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
>            Reporter: Emily Jiang
>            Priority: Critical
>
> We observe a undesired behavior on Weld,  which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
>   lib\myLib.jar (LibExtensionA.class, LibOne.class)
>   myWarA.war (WarAExtension.class, myWarAServlet.class)
>   myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of 
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From manovotn at redhat.com  Wed May 24 05:13:41 2017
From: manovotn at redhat.com (Matej Novotny)
Date: Wed, 24 May 2017 05:13:41 -0400 (EDT)
Subject: [cdi-dev] What, if any,
 guarantees are made about invoking asynchronous event observer
 methods?
In-Reply-To: <CAHNdxukijOTeup9qAnpAsyi5-Tst9FH2myeojjSL6Jrn6Gsqfw@mail.gmail.com>
References: <CAHNdxu=JCut+NmMHiTSPaNxs6n2c54ASRbN6A8Rx4EfpEr=a_A@mail.gmail.com>
	<1144041245.7137007.1494569991649.JavaMail.zimbra@redhat.com>
	<CAHNdxumDNYdwLr0WxG2W2XvH0EDLrZFeBNhnhr0ihRbPMUwk8A@mail.gmail.com>
	<CAHNdxu=j9AzbJBX=Y+_PL1+651-zoO=5UWoZYFeVDu3hR8X7Mw@mail.gmail.com>
	<269237304.7826848.1494832402361.JavaMail.zimbra@redhat.com>
	<CAHNdxukijOTeup9qAnpAsyi5-Tst9FH2myeojjSL6Jrn6Gsqfw@mail.gmail.com>
Message-ID: <81075429.13289272.1495617221907.JavaMail.zimbra@redhat.com>

Hey Laird, 

managed to figure out your TestScenario3[1] with FJP in single thread.
I feel silly for not noticing earlier, but the only real problem is that your test GH project used Weld 3.0.0.CR2[2] and the actual parallel option was added in 3.0.0.Final[3].
So, just upgrade your POM to 3.0.0.Final and it will magically work :)

Matej

_________________________________________________________________________________________________________
[1]https://github.com/ljnelson/weld-570/blob/master/src/test/java/weld/weld570/TestScenario3.java
[2]https://github.com/ljnelson/weld-570/blob/master/pom.xml#L63
[3]https://issues.jboss.org/browse/WELD-2353


----- Original Message -----
> From: "Laird Nelson" <ljnelson at gmail.com>
> To: "Matej Novotny" <manovotn at redhat.com>
> Cc: "cdi-dev" <cdi-dev at lists.jboss.org>
> Sent: Monday, May 15, 2017 5:25:10 PM
> Subject: Re: [cdi-dev] What, if any, guarantees are made about invoking asynchronous event observer methods?
> 
> On Mon, May 15, 2017 at 12:13 AM Matej Novotny <manovotn at redhat.com> wrote:
> 
> > TestScenario1/2 are pretty much what we are discussing here - the
> > container terminates and observers don't get notified any more.
> > Obviously, if you hang any additional 'thenRun' etc. on top of that, it
> > won't work either.
> >
> 
> Right.
> 
> 
> > TestScenario3 is with Weld parallel mode and is IMO out of scope of
> > previous discussion but important nonetheless.
> >
> 
> Yeah?this git repo was less a reproducer and more just me playing around.
> :-)
> 
> 
> > This is indeed weird and I think you are observing a peculiar behaviour of
> > default executor in SE, which is ForkJoinPool.
> > We have a test[1] for parallel execution in SE, where we defined your own
> > executor (see 'createWeld' method) and it works like a charm.
> > I think we need to look into FJP to see what's truly going on there.
> >
> 
> Oh, that is interesting.  OK; thanks.
> 
> Best,
> Laird
> 


From issues at jboss.org  Mon May 29 09:47:00 2017
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 29 May 2017 09:47:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on
 InjectionPoint,
 and what happens when an InjectionPoint is injected into a Decorator
In-Reply-To: <JIRA.12428902.1295985650000@Atlassian.JIRA>
References: <JIRA.12428902.1295985650000@Atlassian.JIRA>
	<JIRA.12428902.1295985650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12428902.1295985650000.41028.1496065620663@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13413054#comment-13413054 ] 

Tomas Remes commented on CDI-78:
--------------------------------

[~antoinesabot-durand] This is still unclear to me what should happen when I inject {{InjectionPoint}} in decorator. Section {{6.5.4. Contextual reference for a bean}} states:
{quote}
The container must ensure that every injection point of type InjectionPoint and qualifier @Default
of any dependent object instantiated during this process receives:
? an instance of InjectionPoint representing the injection point into which the dependent object
will be injected, or
? a null value if it is not being injected into any injection point.
{quote}

Will I get null or instance of {{InjectionPoint}} for the IP injected into decorator?


> Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-78
>                 URL: https://issues.jboss.org/browse/CDI-78
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Decorators
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>            Assignee: Pete Muir
>              Labels: F2F2016
>
> The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From john.ament at spartasystems.com  Mon May 29 11:17:16 2017
From: john.ament at spartasystems.com (John Ament)
Date: Mon, 29 May 2017 15:17:16 +0000
Subject: [cdi-dev] Clarification - how does addPackages work?
Message-ID: <BLUPR04MB6609A57A7489C7A896ADEEC98F30@BLUPR04MB660.namprd04.prod.outlook.com>

While porting the CDI spec to the geronimo project, I noticed that SeContainerInitializer#addPackages (without the boolean) doesn't specify whether its recursive or not.  I believe its not recursive but wanted to confirm this.  E.g. the behavior is the same as calling addPackages(false, Package....)


John



________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170529/c6df7fab/attachment.html 

From manovotn at redhat.com  Mon May 29 12:40:24 2017
From: manovotn at redhat.com (Matej Novotny)
Date: Mon, 29 May 2017 12:40:24 -0400 (EDT)
Subject: [cdi-dev] Clarification - how does addPackages work?
In-Reply-To: <BLUPR04MB6609A57A7489C7A896ADEEC98F30@BLUPR04MB660.namprd04.prod.outlook.com>
References: <BLUPR04MB6609A57A7489C7A896ADEEC98F30@BLUPR04MB660.namprd04.prod.outlook.com>
Message-ID: <1441197890.15460312.1496076024182.JavaMail.zimbra@redhat.com>

Hi John,

I can confirm that Weld implements it exactly as you expect it.
E.g. Weld does NOT scan recursively by default.

Matej

----- Original Message -----
> From: "John Ament" <john.ament at spartasystems.com>
> To: "cdi-dev" <cdi-dev at lists.jboss.org>
> Sent: Monday, May 29, 2017 5:17:16 PM
> Subject: [cdi-dev] Clarification - how does addPackages work?
> 
> 
> 
> While porting the CDI spec to the geronimo project, I noticed that
> SeContainerInitializer#addPackages (without the boolean) doesn't specify
> whether its recursive or not. I believe its not recursive but wanted to
> confirm this. E.g. the behavior is the same as calling addPackages(false,
> Package....)
> 
> 
> 
> 
> John
> 
> 
> 
> 
> 
> 
> 
> 
> 
> NOTICE: This e-mail message and any attachments may contain confidential,
> proprietary, and/or privileged information which should be treated
> accordingly. If you are not the intended recipient, please notify the sender
> immediately by return e-mail, delete this message, and destroy all physical
> and electronic copies. Thank you.
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.

From mkouba at redhat.com  Tue May 30 01:33:50 2017
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 30 May 2017 07:33:50 +0200
Subject: [cdi-dev] Clarification - how does addPackages work?
In-Reply-To: <1441197890.15460312.1496076024182.JavaMail.zimbra@redhat.com>
References: <BLUPR04MB6609A57A7489C7A896ADEEC98F30@BLUPR04MB660.namprd04.prod.outlook.com>
	<1441197890.15460312.1496076024182.JavaMail.zimbra@redhat.com>
Message-ID: <e5b942f1-4573-63bb-4722-e86b8f4efc71@redhat.com>

In fact, this method should probably have a default impl calling 
addPackages(false, packageClasses). Otherwise the wording seems accurate 
to me.

Martin

Dne 29.5.2017 v 18:40 Matej Novotny napsal(a):
> Hi John,
> 
> I can confirm that Weld implements it exactly as you expect it.
> E.g. Weld does NOT scan recursively by default.
> 
> Matej
> 
> ----- Original Message -----
>> From: "John Ament" <john.ament at spartasystems.com>
>> To: "cdi-dev" <cdi-dev at lists.jboss.org>
>> Sent: Monday, May 29, 2017 5:17:16 PM
>> Subject: [cdi-dev] Clarification - how does addPackages work?
>>
>>
>>
>> While porting the CDI spec to the geronimo project, I noticed that
>> SeContainerInitializer#addPackages (without the boolean) doesn't specify
>> whether its recursive or not. I believe its not recursive but wanted to
>> confirm this. E.g. the behavior is the same as calling addPackages(false,
>> Package....)
>>
>>
>>
>>
>> John
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> NOTICE: This e-mail message and any attachments may contain confidential,
>> proprietary, and/or privileged information which should be treated
>> accordingly. If you are not the intended recipient, please notify the sender
>> immediately by return e-mail, delete this message, and destroy all physical
>> and electronic copies. Thank you.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From issues at jboss.org  Tue May 30 01:54:00 2017
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Tue, 30 May 2017 01:54:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on
 InjectionPoint,
 and what happens when an InjectionPoint is injected into a Decorator
In-Reply-To: <JIRA.12428902.1295985650000@Atlassian.JIRA>
References: <JIRA.12428902.1295985650000@Atlassian.JIRA>
	<JIRA.12428902.1295985650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12428902.1295985650000.43128.1496123640318@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes reopened CDI-78:
----------------------------
      Assignee:     (was: Pete Muir)


See my previous comment.

> Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-78
>                 URL: https://issues.jboss.org/browse/CDI-78
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Decorators
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>              Labels: F2F2016
>
> The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From manovotn at redhat.com  Tue May 30 02:25:24 2017
From: manovotn at redhat.com (Matej Novotny)
Date: Tue, 30 May 2017 02:25:24 -0400 (EDT)
Subject: [cdi-dev] Clarification - how does addPackages work?
In-Reply-To: <e5b942f1-4573-63bb-4722-e86b8f4efc71@redhat.com>
References: <BLUPR04MB6609A57A7489C7A896ADEEC98F30@BLUPR04MB660.namprd04.prod.outlook.com>
	<1441197890.15460312.1496076024182.JavaMail.zimbra@redhat.com>
	<e5b942f1-4573-63bb-4722-e86b8f4efc71@redhat.com>
Message-ID: <1882392784.15515658.1496125524896.JavaMail.zimbra@redhat.com>

> In fact, this method should probably have a default impl

+1 for such default impl, that would make perfect sense.

> Otherwise the wording seems accurate

What wording? I glanced at spec/javadoc and it doesn't seem to mention whether it is by default recursive.

Matej

----- Original Message -----
> From: "Martin Kouba" <mkouba at redhat.com>
> To: "Matej Novotny" <manovotn at redhat.com>, "John Ament" <john.ament at spartasystems.com>
> Cc: "cdi-dev" <cdi-dev at lists.jboss.org>
> Sent: Tuesday, May 30, 2017 7:33:50 AM
> Subject: Re: [cdi-dev] Clarification - how does addPackages work?
> 
> In fact, this method should probably have a default impl calling
> addPackages(false, packageClasses). Otherwise the wording seems accurate
> to me.
> 
> Martin
> 
> Dne 29.5.2017 v 18:40 Matej Novotny napsal(a):
> > Hi John,
> > 
> > I can confirm that Weld implements it exactly as you expect it.
> > E.g. Weld does NOT scan recursively by default.
> > 
> > Matej
> > 
> > ----- Original Message -----
> >> From: "John Ament" <john.ament at spartasystems.com>
> >> To: "cdi-dev" <cdi-dev at lists.jboss.org>
> >> Sent: Monday, May 29, 2017 5:17:16 PM
> >> Subject: [cdi-dev] Clarification - how does addPackages work?
> >>
> >>
> >>
> >> While porting the CDI spec to the geronimo project, I noticed that
> >> SeContainerInitializer#addPackages (without the boolean) doesn't specify
> >> whether its recursive or not. I believe its not recursive but wanted to
> >> confirm this. E.g. the behavior is the same as calling addPackages(false,
> >> Package....)
> >>
> >>
> >>
> >>
> >> John
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> NOTICE: This e-mail message and any attachments may contain confidential,
> >> proprietary, and/or privileged information which should be treated
> >> accordingly. If you are not the intended recipient, please notify the
> >> sender
> >> immediately by return e-mail, delete this message, and destroy all
> >> physical
> >> and electronic copies. Thank you.
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code
> >> under the Apache License, Version 2
> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >> provided on this list, the provider waives all patent and other
> >> intellectual
> >> property rights inherent in such information.
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > 
> > Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2
> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual property rights inherent in such information.
> > 
> 
> --
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
> 

From mkouba at redhat.com  Tue May 30 02:27:18 2017
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 30 May 2017 08:27:18 +0200
Subject: [cdi-dev] Clarification - how does addPackages work?
In-Reply-To: <1882392784.15515658.1496125524896.JavaMail.zimbra@redhat.com>
References: <BLUPR04MB6609A57A7489C7A896ADEEC98F30@BLUPR04MB660.namprd04.prod.outlook.com>
	<1441197890.15460312.1496076024182.JavaMail.zimbra@redhat.com>
	<e5b942f1-4573-63bb-4722-e86b8f4efc71@redhat.com>
	<1882392784.15515658.1496125524896.JavaMail.zimbra@redhat.com>
Message-ID: <7268d8b8-7ab6-1ab7-bcaa-c011374c5536@redhat.com>

Dne 30.5.2017 v 08:25 Matej Novotny napsal(a):
>> In fact, this method should probably have a default impl
> 
> +1 for such default impl, that would make perfect sense.
> 
>> Otherwise the wording seems accurate
> 
> What wording? I glanced at spec/javadoc and it doesn't seem to mention whether it is by default recursive.

Exactly. It's very clear that only classes from the packages of the 
specified classes will be added. Note that Java does not define anything 
like a "subpackage".

> 
> Matej
> 
> ----- Original Message -----
>> From: "Martin Kouba" <mkouba at redhat.com>
>> To: "Matej Novotny" <manovotn at redhat.com>, "John Ament" <john.ament at spartasystems.com>
>> Cc: "cdi-dev" <cdi-dev at lists.jboss.org>
>> Sent: Tuesday, May 30, 2017 7:33:50 AM
>> Subject: Re: [cdi-dev] Clarification - how does addPackages work?
>>
>> In fact, this method should probably have a default impl calling
>> addPackages(false, packageClasses). Otherwise the wording seems accurate
>> to me.
>>
>> Martin
>>
>> Dne 29.5.2017 v 18:40 Matej Novotny napsal(a):
>>> Hi John,
>>>
>>> I can confirm that Weld implements it exactly as you expect it.
>>> E.g. Weld does NOT scan recursively by default.
>>>
>>> Matej
>>>
>>> ----- Original Message -----
>>>> From: "John Ament" <john.ament at spartasystems.com>
>>>> To: "cdi-dev" <cdi-dev at lists.jboss.org>
>>>> Sent: Monday, May 29, 2017 5:17:16 PM
>>>> Subject: [cdi-dev] Clarification - how does addPackages work?
>>>>
>>>>
>>>>
>>>> While porting the CDI spec to the geronimo project, I noticed that
>>>> SeContainerInitializer#addPackages (without the boolean) doesn't specify
>>>> whether its recursive or not. I believe its not recursive but wanted to
>>>> confirm this. E.g. the behavior is the same as calling addPackages(false,
>>>> Package....)
>>>>
>>>>
>>>>
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> NOTICE: This e-mail message and any attachments may contain confidential,
>>>> proprietary, and/or privileged information which should be treated
>>>> accordingly. If you are not the intended recipient, please notify the
>>>> sender
>>>> immediately by return e-mail, delete this message, and destroy all
>>>> physical
>>>> and electronic copies. Thank you.
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the
>>>> code
>>>> under the Apache License, Version 2
>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>> provided on this list, the provider waives all patent and other
>>>> intellectual
>>>> property rights inherent in such information.
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other
>>> intellectual property rights inherent in such information.
>>>
>>
>> --
>> Martin Kouba
>> Senior Software Engineer
>> Red Hat, Czech Republic
>>

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From issues at jboss.org  Tue May 30 03:19:00 2017
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 May 2017 03:19:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-703) Carify indirect specialization
In-Reply-To: <JIRA.12694714.1496128693000@Atlassian.JIRA>
References: <JIRA.12694714.1496128693000@Atlassian.JIRA>
	<JIRA.12694714.1496128693589@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12694714.1496128693000.43584.1496128740064@Atlassian.JIRA>

Antoine Sabot-Durand created CDI-703:
----------------------------------------

             Summary: Carify indirect specialization
                 Key: CDI-703
                 URL: https://issues.jboss.org/browse/CDI-703
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Inheritance and Specialization
    Affects Versions: 2.0 .Final
            Reporter: Antoine Sabot-Durand


Indirect specialization in chapter 4.3.1 lacks clarification regarding intermediate beans attributes (qualifier) and final bean.
Discussion in CDITCK-580 illustrates this concern.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue May 30 03:21:00 2017
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 May 2017 03:21:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-703) Carify indirect specialization
In-Reply-To: <JIRA.12694714.1496128694000@Atlassian.JIRA>
References: <JIRA.12694714.1496128694000@Atlassian.JIRA>
	<JIRA.12694714.1496128694000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12694714.1496128694000.43585.1496128860114@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-703:
-------------------------------------
    Description: 
Indirect specialization in chapter 4.3.1 lacks clarification regarding intermediate beans attributes (qualifier and name) on specializing bean bean.
Discussion in CDITCK-580 illustrates this concern.

  was:
Indirect specialization in chapter 4.3.1 lacks clarification regarding intermediate beans attributes (qualifier) and final bean.
Discussion in CDITCK-580 illustrates this concern.



> Carify indirect specialization
> ------------------------------
>
>                 Key: CDI-703
>                 URL: https://issues.jboss.org/browse/CDI-703
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Inheritance and Specialization
>    Affects Versions: 2.0 .Final
>            Reporter: Antoine Sabot-Durand
>
> Indirect specialization in chapter 4.3.1 lacks clarification regarding intermediate beans attributes (qualifier and name) on specializing bean bean.
> Discussion in CDITCK-580 illustrates this concern.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue May 30 03:35:00 2017
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Tue, 30 May 2017 03:35:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-703) Carify indirect specialization
In-Reply-To: <JIRA.12694714.1496128694000@Atlassian.JIRA>
References: <JIRA.12694714.1496128694000@Atlassian.JIRA>
	<JIRA.12694714.1496128694000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12694714.1496128694000.43645.1496129700126@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13413392#comment-13413392 ] 

Matej Novotny commented on CDI-703:
-----------------------------------

What part exactly would you like to clarify?

As a part of CDI-441 (2.0) we enhanced the wording making it clear that the relation is *transitive*.
And that, in my opinion, should have quite clear implications in this regard.

> Carify indirect specialization
> ------------------------------
>
>                 Key: CDI-703
>                 URL: https://issues.jboss.org/browse/CDI-703
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Inheritance and Specialization
>    Affects Versions: 2.0 .Final
>            Reporter: Antoine Sabot-Durand
>
> Indirect specialization in chapter 4.3.1 lacks clarification regarding intermediate beans attributes (qualifier and name) on specializing bean bean.
> Discussion in CDITCK-580 illustrates this concern.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue May 30 04:17:00 2017
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 May 2017 04:17:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on
 InjectionPoint,
 and what happens when an InjectionPoint is injected into a Decorator
In-Reply-To: <JIRA.12428902.1295985650000@Atlassian.JIRA>
References: <JIRA.12428902.1295985650000@Atlassian.JIRA>
	<JIRA.12428902.1295985650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12428902.1295985650000.43791.1496132220707@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13413414#comment-13413414 ] 

Antoine Sabot-Durand commented on CDI-78:
-----------------------------------------

2 scenarios here.

h2. InjectionPoint relates to the decorator bean itself

As a decorator can't be injected directly since it's not available for injection as stated in 5.1.4, so {{InjectionPoint}} of a decorator should always return null.

h2. InjectionPoint relates to the decorated bean

It could be nice to have information about {{InjectionPoint}} of the decorated bean in the decorator, but it can be confusing to deal with it: decorator can decorate dependent and non-dependent beans at the same time. So, if we don't want to break the spec, we should forbid it if at leat one decorated bean is not dependent.

h2. My proposal

{{InjectionPoint}} with @Default qualifier injected in decorator (or interceptor BTW), should be considered as scenario 1 and always return null.

To support injection of decorated bean's {{InjectionPoint}} we should use the {{@Decorated}} qualifier ({{@Inject @Decorated  InjectionPoint}}) allowing to have the IP instance if decorated bean is dependent or null if it is not. It won't violate the spec and be less confusing for users (we can assume that a user adding such a qualifier probably knows what he's doing).

Again this proposal is also interesting for Interceptors.

WDYT ?

> Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-78
>                 URL: https://issues.jboss.org/browse/CDI-78
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Decorators
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>              Labels: F2F2016
>
> The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue May 30 04:21:00 2017
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 May 2017 04:21:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on
 InjectionPoint,
 and what happens when an InjectionPoint is injected into a Decorator
In-Reply-To: <JIRA.12428902.1295985650000@Atlassian.JIRA>
References: <JIRA.12428902.1295985650000@Atlassian.JIRA>
	<JIRA.12428902.1295985650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12428902.1295985650000.43816.1496132460461@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13413414#comment-13413414 ] 

Antoine Sabot-Durand edited comment on CDI-78 at 5/30/17 4:20 AM:
------------------------------------------------------------------

2 scenarios here.

h2. InjectionPoint relates to the decorator bean itself

As a decorator can't be injected directly since it's not available for injection as stated in 5.1.4, so {{InjectionPoint}} of a decorator should always return null.

h2. InjectionPoint relates to the decorated bean

It could be nice to have information about {{InjectionPoint}} of the decorated bean in the decorator, but it can be confusing to deal with it: decorator can decorate dependent and non-dependent beans at the same time. So, if we don't want to break the spec, we should forbid it if at least one decorated bean is not dependent.

h2. My proposal

{{InjectionPoint}} with @Default qualifier injected in decorator (or interceptor BTW), should be considered as scenario 1 and always return null.

To support injection of decorated bean's {{InjectionPoint}} we should use the {{@Decorated}} qualifier ({{@Inject @Decorated  InjectionPoint}}) allowing to have the IP instance if decorated bean is dependent or null if it is not. It won't violate the spec and be less confusing for users (we can assume that a user adding such a qualifier probably knows what he's doing).

Again this proposal is also interesting for Interceptors.

WDYT ?


was (Author: antoinesabot-durand):
2 scenarios here.

h2. InjectionPoint relates to the decorator bean itself

As a decorator can't be injected directly since it's not available for injection as stated in 5.1.4, so {{InjectionPoint}} of a decorator should always return null.

h2. InjectionPoint relates to the decorated bean

It could be nice to have information about {{InjectionPoint}} of the decorated bean in the decorator, but it can be confusing to deal with it: decorator can decorate dependent and non-dependent beans at the same time. So, if we don't want to break the spec, we should forbid it if at leat one decorated bean is not dependent.

h2. My proposal

{{InjectionPoint}} with @Default qualifier injected in decorator (or interceptor BTW), should be considered as scenario 1 and always return null.

To support injection of decorated bean's {{InjectionPoint}} we should use the {{@Decorated}} qualifier ({{@Inject @Decorated  InjectionPoint}}) allowing to have the IP instance if decorated bean is dependent or null if it is not. It won't violate the spec and be less confusing for users (we can assume that a user adding such a qualifier probably knows what he's doing).

Again this proposal is also interesting for Interceptors.

WDYT ?

> Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-78
>                 URL: https://issues.jboss.org/browse/CDI-78
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Decorators
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>              Labels: F2F2016
>
> The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue May 30 04:30:00 2017
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 May 2017 04:30:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on
 InjectionPoint,
 and what happens when an InjectionPoint is injected into a Decorator
In-Reply-To: <JIRA.12428902.1295985650000@Atlassian.JIRA>
References: <JIRA.12428902.1295985650000@Atlassian.JIRA>
	<JIRA.12428902.1295985650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12428902.1295985650000.43853.1496133000541@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-78:
------------------------------------
    Fix Version/s: 2.1 (Discussion)


> Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-78
>                 URL: https://issues.jboss.org/browse/CDI-78
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Decorators
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>              Labels: F2F2016
>             Fix For: 2.1 (Discussion)
>
>
> The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From john.ament at spartasystems.com  Tue May 30 05:57:09 2017
From: john.ament at spartasystems.com (John Ament)
Date: Tue, 30 May 2017 09:57:09 +0000
Subject: [cdi-dev] Clarification - how does addPackages work?
In-Reply-To: <7268d8b8-7ab6-1ab7-bcaa-c011374c5536@redhat.com>
References: <BLUPR04MB6609A57A7489C7A896ADEEC98F30@BLUPR04MB660.namprd04.prod.outlook.com>
	<1441197890.15460312.1496076024182.JavaMail.zimbra@redhat.com>
	<e5b942f1-4573-63bb-4722-e86b8f4efc71@redhat.com>
	<1882392784.15515658.1496125524896.JavaMail.zimbra@redhat.com>,
	<7268d8b8-7ab6-1ab7-bcaa-c011374c5536@redhat.com>
Message-ID: <BLUPR04MB66044D628F3D7E1DA1970F598F00@BLUPR04MB660.namprd04.prod.outlook.com>

If I had to guess, by default method you're thinking something like this:


    public default SeContainerInitializer addPackages(Class<?>... classes) {
        return addPackages(false, classes);
    }




________________________________
From: Martin Kouba <mkouba at redhat.com>
Sent: Tuesday, May 30, 2017 2:27 AM
To: Matej Novotny
Cc: John Ament; cdi-dev
Subject: Re: [cdi-dev] Clarification - how does addPackages work?

Dne 30.5.2017 v 08:25 Matej Novotny napsal(a):
>> In fact, this method should probably have a default impl
>
> +1 for such default impl, that would make perfect sense.
>
>> Otherwise the wording seems accurate
>
> What wording? I glanced at spec/javadoc and it doesn't seem to mention whether it is by default recursive.

Exactly. It's very clear that only classes from the packages of the
specified classes will be added. Note that Java does not define anything
like a "subpackage".

>
> Matej
>
> ----- Original Message -----
>> From: "Martin Kouba" <mkouba at redhat.com>
>> To: "Matej Novotny" <manovotn at redhat.com>, "John Ament" <john.ament at spartasystems.com>
>> Cc: "cdi-dev" <cdi-dev at lists.jboss.org>
>> Sent: Tuesday, May 30, 2017 7:33:50 AM
>> Subject: Re: [cdi-dev] Clarification - how does addPackages work?
>>
>> In fact, this method should probably have a default impl calling
>> addPackages(false, packageClasses). Otherwise the wording seems accurate
>> to me.
>>
>> Martin
>>
>> Dne 29.5.2017 v 18:40 Matej Novotny napsal(a):
>>> Hi John,
>>>
>>> I can confirm that Weld implements it exactly as you expect it.
>>> E.g. Weld does NOT scan recursively by default.
>>>
>>> Matej
>>>
>>> ----- Original Message -----
>>>> From: "John Ament" <john.ament at spartasystems.com>
>>>> To: "cdi-dev" <cdi-dev at lists.jboss.org>
>>>> Sent: Monday, May 29, 2017 5:17:16 PM
>>>> Subject: [cdi-dev] Clarification - how does addPackages work?
>>>>
>>>>
>>>>
>>>> While porting the CDI spec to the geronimo project, I noticed that
>>>> SeContainerInitializer#addPackages (without the boolean) doesn't specify
>>>> whether its recursive or not. I believe its not recursive but wanted to
>>>> confirm this. E.g. the behavior is the same as calling addPackages(false,
>>>> Package....)
>>>>
>>>>
>>>>
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> NOTICE: This e-mail message and any attachments may contain confidential,
>>>> proprietary, and/or privileged information which should be treated
>>>> accordingly. If you are not the intended recipient, please notify the
>>>> sender
>>>> immediately by return e-mail, delete this message, and destroy all
>>>> physical
>>>> and electronic copies. Thank you.
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the
>>>> code
>>>> under the Apache License, Version 2
>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>> provided on this list, the provider waives all patent and other
>>>> intellectual
>>>> property rights inherent in such information.
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other
>>> intellectual property rights inherent in such information.
>>>
>>
>> --
>> Martin Kouba
>> Senior Software Engineer
>> Red Hat, Czech Republic
>>

--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170530/52160b99/attachment-0001.html 

From issues at jboss.org  Tue May 30 05:59:00 2017
From: issues at jboss.org (John Ament (JIRA))
Date: Tue, 30 May 2017 05:59:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-704) Clarify that
 SeContainerInitializer.addPackages is by default not recursive
In-Reply-To: <JIRA.12694759.1496138328000@Atlassian.JIRA>
References: <JIRA.12694759.1496138328000@Atlassian.JIRA>
	<JIRA.12694759.1496138328768@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12694759.1496138328000.45045.1496138340878@Atlassian.JIRA>

John Ament created CDI-704:
------------------------------

             Summary: Clarify that SeContainerInitializer.addPackages is by default not recursive
                 Key: CDI-704
                 URL: https://issues.jboss.org/browse/CDI-704
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: John Ament


Neither the spec nor the javadocs make it clear that this method is by default not recursive, the equivalent of calling addPackages(false, ...)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From mkouba at redhat.com  Tue May 30 06:04:25 2017
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 30 May 2017 12:04:25 +0200
Subject: [cdi-dev] Clarification - how does addPackages work?
In-Reply-To: <BLUPR04MB66044D628F3D7E1DA1970F598F00@BLUPR04MB660.namprd04.prod.outlook.com>
References: <BLUPR04MB6609A57A7489C7A896ADEEC98F30@BLUPR04MB660.namprd04.prod.outlook.com>
	<1441197890.15460312.1496076024182.JavaMail.zimbra@redhat.com>
	<e5b942f1-4573-63bb-4722-e86b8f4efc71@redhat.com>
	<1882392784.15515658.1496125524896.JavaMail.zimbra@redhat.com>
	<7268d8b8-7ab6-1ab7-bcaa-c011374c5536@redhat.com>
	<BLUPR04MB66044D628F3D7E1DA1970F598F00@BLUPR04MB660.namprd04.prod.outlook.com>
Message-ID: <e227a0dc-5b15-2f06-21ba-3d9e101a9b1b@redhat.com>

Yes, except for the "default" keyword - it's an abstract class. So just 
"public SeContainerInitializer addPackages(Class<?>... packageClasses) 
{...}".

Dne 30.5.2017 v 11:57 John Ament napsal(a):
> If I had to guess, by default method you're thinking something like this:
> 
> 
>      public default SeContainerInitializer addPackages(Class<?>... 
> classes) {
>          return addPackages(false, classes);
>      }
> 
> 
> 
> 
> ------------------------------------------------------------------------
> *From:* Martin Kouba <mkouba at redhat.com>
> *Sent:* Tuesday, May 30, 2017 2:27 AM
> *To:* Matej Novotny
> *Cc:* John Ament; cdi-dev
> *Subject:* Re: [cdi-dev] Clarification - how does addPackages work?
> Dne 30.5.2017 v 08:25 Matej Novotny napsal(a):
>>> In fact, this method should probably have a default impl
>> 
>> +1 for such default impl, that would make perfect sense.
>> 
>>> Otherwise the wording seems accurate
>> 
>> What wording? I glanced at spec/javadoc and it doesn't seem to mention whether it is by default recursive.
> 
> Exactly. It's very clear that only classes from the packages of the
> specified classes will be added. Note that Java does not define anything
> like a "subpackage".
> 
>> 
>> Matej
>> 
>> ----- Original Message -----
>>> From: "Martin Kouba" <mkouba at redhat.com>
>>> To: "Matej Novotny" <manovotn at redhat.com>, "John Ament" <john.ament at spartasystems.com>
>>> Cc: "cdi-dev" <cdi-dev at lists.jboss.org>
>>> Sent: Tuesday, May 30, 2017 7:33:50 AM
>>> Subject: Re: [cdi-dev] Clarification - how does addPackages work?
>>>
>>> In fact, this method should probably have a default impl calling
>>> addPackages(false, packageClasses). Otherwise the wording seems accurate
>>> to me.
>>>
>>> Martin
>>>
>>> Dne 29.5.2017 v 18:40 Matej Novotny napsal(a):
>>>> Hi John,
>>>>
>>>> I can confirm that Weld implements it exactly as you expect it.
>>>> E.g. Weld does NOT scan recursively by default.
>>>>
>>>> Matej
>>>>
>>>> ----- Original Message -----
>>>>> From: "John Ament" <john.ament at spartasystems.com>
>>>>> To: "cdi-dev" <cdi-dev at lists.jboss.org>
>>>>> Sent: Monday, May 29, 2017 5:17:16 PM
>>>>> Subject: [cdi-dev] Clarification - how does addPackages work?
>>>>>
>>>>>
>>>>>
>>>>> While porting the CDI spec to the geronimo project, I noticed that
>>>>> SeContainerInitializer#addPackages (without the boolean) doesn't specify
>>>>> whether its recursive or not. I believe its not recursive but wanted to
>>>>> confirm this. E.g. the behavior is the same as calling addPackages(false,
>>>>> Package....)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> NOTICE: This e-mail message and any attachments may contain confidential,
>>>>> proprietary, and/or privileged information which should be treated
>>>>> accordingly. If you are not the intended recipient, please notify the
>>>>> sender
>>>>> immediately by return e-mail, delete this message, and destroy all
>>>>> physical
>>>>> and electronic copies. Thank you.
>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>> Note that for all code provided on this list, the provider licenses the
>>>>> code
>>>>> under the Apache License, Version 2
>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>> provided on this list, the provider waives all patent and other
>>>>> intellectual
>>>>> property rights inherent in such information.
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the
>>>> code under the Apache License, Version 2
>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>> provided on this list, the provider waives all patent and other
>>>> intellectual property rights inherent in such information.
>>>>
>>>
>>> --
>>> Martin Kouba
>>> Senior Software Engineer
>>> Red Hat, Czech Republic
>>>
> 
> -- 
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain 
> confidential, proprietary, and/or privileged information which should be 
> treated accordingly. If you are not the intended recipient, please 
> notify the sender immediately by return e-mail, delete this message, and 
> destroy all physical and electronic copies. Thank you.

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From issues at jboss.org  Wed May 31 12:18:01 2017
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Wed, 31 May 2017 12:18:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-703) Carify indirect specialization
In-Reply-To: <JIRA.12694714.1496128694000@Atlassian.JIRA>
References: <JIRA.12694714.1496128694000@Atlassian.JIRA>
	<JIRA.12694714.1496128694000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12694714.1496128694000.55892.1496247481213@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414522#comment-13414522 ] 

Mark Struberg commented on CDI-703:
-----------------------------------

[~manovotn] CDI-441 makes clear that the rules don't only apply to X extends Z extends Y but also X extends Z2 extends Z1 extends Y situations.

But it does not even mention Qualifiers... 

> Carify indirect specialization
> ------------------------------
>
>                 Key: CDI-703
>                 URL: https://issues.jboss.org/browse/CDI-703
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Inheritance and Specialization
>    Affects Versions: 2.0 .Final
>            Reporter: Antoine Sabot-Durand
>
> Indirect specialization in chapter 4.3.1 lacks clarification regarding intermediate beans attributes (qualifier and name) on specializing bean bean.
> Discussion in CDITCK-580 illustrates this concern.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)