From antoine at sabot-durand.net  Thu Jul  2 06:08:44 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 2 Jul 2015 12:08:44 +0200
Subject: [cdi-dev] CDI 2.0 EDR1 hit maven central
Message-ID: <7CA83C2C-9084-4CFD-8391-59DACC436AFA@sabot-durand.net>

Hi,

For your info, CDI 2.0 hit maven central yesterday. I should post the release on the blog today.

Regards,

Antoine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150702/e6f0d91a/attachment-0001.bin 

From antoine at sabot-durand.net  Fri Jul  3 09:12:13 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Fri, 3 Jul 2015 15:12:13 +0200
Subject: [cdi-dev] CDI 2.0 release is official
Message-ID: <6AB1D754-CA47-4558-81BB-ED03A8CFD95A@sabot-durand.net>

Hi guys,


You can communicate on it or give me your feedback on the post

http://cdi-spec.org/news/2015/07/03/CDI-2_0-EDR1-released/ <http://cdi-spec.org/news/2015/07/03/CDI-2_0-EDR1-released/>

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150703/c98422d6/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150703/c98422d6/attachment.bin 

From john.d.ament at gmail.com  Fri Jul  3 09:41:59 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Fri, 03 Jul 2015 13:41:59 +0000
Subject: [cdi-dev] CDI 2.0 release is official
In-Reply-To: <6AB1D754-CA47-4558-81BB-ED03A8CFD95A@sabot-durand.net>
References: <6AB1D754-CA47-4558-81BB-ED03A8CFD95A@sabot-durand.net>
Message-ID: <CAOqetn_NMDZWQ+V9WJJpUf9uFVgcGcp1ghXM6NvAz8Xdqy+A0w@mail.gmail.com>

Very nice! (though the email subject is a little misleading)

On Fri, Jul 3, 2015 at 9:12 AM Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> Hi guys,
>
>
> You can communicate on it or give me your feedback on the post
>
> http://cdi-spec.org/news/2015/07/03/CDI-2_0-EDR1-released/
>
> Antoine
> _______________________________________________
> 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/20150703/e451d91e/attachment.html 

From antoine at sabot-durand.net  Fri Jul  3 10:17:09 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Fri, 3 Jul 2015 16:17:09 +0200
Subject: [cdi-dev] CDI 2.0 release is official
In-Reply-To: <CAOqetn_NMDZWQ+V9WJJpUf9uFVgcGcp1ghXM6NvAz8Xdqy+A0w@mail.gmail.com>
References: <6AB1D754-CA47-4558-81BB-ED03A8CFD95A@sabot-durand.net>
	<CAOqetn_NMDZWQ+V9WJJpUf9uFVgcGcp1ghXM6NvAz8Xdqy+A0w@mail.gmail.com>
Message-ID: <F80938F0-F88B-4071-8BCD-FD1D82363002@sabot-durand.net>

Of course it's CDI 2.0 EDR1 ;). <bad faith>it was a test to see if someone was actually reading </bad faith>

Antoine

> Le 3 juil. 2015 ? 15:41, John D. Ament <john.d.ament at gmail.com> a ?crit :
> 
> Very nice! (though the email subject is a little misleading)
> 
>> On Fri, Jul 3, 2015 at 9:12 AM Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>> Hi guys,
>> 
>> 
>> You can communicate on it or give me your feedback on the post
>> 
>> http://cdi-spec.org/news/2015/07/03/CDI-2_0-EDR1-released/
>> 
>> Antoine
>> _______________________________________________
>> 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/20150703/2c772cc6/attachment.html 

From arjan.tijms at gmail.com  Sat Jul  4 08:02:06 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 4 Jul 2015 14:02:06 +0200
Subject: [cdi-dev] CDI 2.0 release is official
In-Reply-To: <F80938F0-F88B-4071-8BCD-FD1D82363002@sabot-durand.net>
References: <6AB1D754-CA47-4558-81BB-ED03A8CFD95A@sabot-durand.net>
	<CAOqetn_NMDZWQ+V9WJJpUf9uFVgcGcp1ghXM6NvAz8Xdqy+A0w@mail.gmail.com>
	<F80938F0-F88B-4071-8BCD-FD1D82363002@sabot-durand.net>
Message-ID: <CAE=-AhAbTK_dm007tFWEQb-NEbb8ryaOfrqm4h3d2USr+wxJww@mail.gmail.com>

Hi,

I've got one comment:

>Since the beginning both implementations (JBoss Weld and Apache OpenWebBeans) proposed proprietary solutions to use CDI in Java SE.

Aren't there 3 implementations really? CanDI implements CDI too, doesn't it?

Kind regards,
Arjan Tijms



On Fri, Jul 3, 2015 at 4:17 PM, Antoine Sabot-Durand
<antoine at sabot-durand.net> wrote:
> Of course it's CDI 2.0 EDR1 ;). <bad faith>it was a test to see if someone
> was actually reading </bad faith>
>
> Antoine
>
> Le 3 juil. 2015 ? 15:41, John D. Ament <john.d.ament at gmail.com> a ?crit :
>
> Very nice! (though the email subject is a little misleading)
>
> On Fri, Jul 3, 2015 at 9:12 AM Antoine Sabot-Durand
> <antoine at sabot-durand.net> wrote:
>>
>> Hi guys,
>>
>>
>> You can communicate on it or give me your feedback on the post
>>
>> http://cdi-spec.org/news/2015/07/03/CDI-2_0-EDR1-released/
>>
>> Antoine
>> _______________________________________________
>> 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.


From antoine at sabot-durand.net  Sat Jul  4 10:01:28 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Sat, 04 Jul 2015 14:01:28 +0000
Subject: [cdi-dev] CDI 2.0 release is official
In-Reply-To: <CAE=-AhAbTK_dm007tFWEQb-NEbb8ryaOfrqm4h3d2USr+wxJww@mail.gmail.com>
References: <6AB1D754-CA47-4558-81BB-ED03A8CFD95A@sabot-durand.net>
	<CAOqetn_NMDZWQ+V9WJJpUf9uFVgcGcp1ghXM6NvAz8Xdqy+A0w@mail.gmail.com>
	<F80938F0-F88B-4071-8BCD-FD1D82363002@sabot-durand.net>
	<CAE=-AhAbTK_dm007tFWEQb-NEbb8ryaOfrqm4h3d2USr+wxJww@mail.gmail.com>
Message-ID: <CABu-YBTyb35uWyjqDN90nuRax5gp=u3mu3L-a1_bNvyy7eBbfA@mail.gmail.com>

Candi implements CDI 1.0 and never provided solution for java SE. To my
knowledge that don't have plan for CDI 1.2 or 2.0.

Antoine
Le sam. 4 juil. 2015 ? 14:02, arjan tijms <arjan.tijms at gmail.com> a ?crit :

> Hi,
>
> I've got one comment:
>
> >Since the beginning both implementations (JBoss Weld and Apache
> OpenWebBeans) proposed proprietary solutions to use CDI in Java SE.
>
> Aren't there 3 implementations really? CanDI implements CDI too, doesn't
> it?
>
> Kind regards,
> Arjan Tijms
>
>
>
> On Fri, Jul 3, 2015 at 4:17 PM, Antoine Sabot-Durand
> <antoine at sabot-durand.net> wrote:
> > Of course it's CDI 2.0 EDR1 ;). <bad faith>it was a test to see if
> someone
> > was actually reading </bad faith>
> >
> > Antoine
> >
> > Le 3 juil. 2015 ? 15:41, John D. Ament <john.d.ament at gmail.com> a ?crit
> :
> >
> > Very nice! (though the email subject is a little misleading)
> >
> > On Fri, Jul 3, 2015 at 9:12 AM Antoine Sabot-Durand
> > <antoine at sabot-durand.net> wrote:
> >>
> >> Hi guys,
> >>
> >>
> >> You can communicate on it or give me your feedback on the post
> >>
> >> http://cdi-spec.org/news/2015/07/03/CDI-2_0-EDR1-released/
> >>
> >> Antoine
> >> _______________________________________________
> >> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150704/cc3b6015/attachment.html 

From arjan.tijms at gmail.com  Sat Jul  4 14:15:49 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 4 Jul 2015 20:15:49 +0200
Subject: [cdi-dev] CDI 2.0 release is official
In-Reply-To: <CABu-YBTyb35uWyjqDN90nuRax5gp=u3mu3L-a1_bNvyy7eBbfA@mail.gmail.com>
References: <6AB1D754-CA47-4558-81BB-ED03A8CFD95A@sabot-durand.net>
	<CAOqetn_NMDZWQ+V9WJJpUf9uFVgcGcp1ghXM6NvAz8Xdqy+A0w@mail.gmail.com>
	<F80938F0-F88B-4071-8BCD-FD1D82363002@sabot-durand.net>
	<CAE=-AhAbTK_dm007tFWEQb-NEbb8ryaOfrqm4h3d2USr+wxJww@mail.gmail.com>
	<CABu-YBTyb35uWyjqDN90nuRax5gp=u3mu3L-a1_bNvyy7eBbfA@mail.gmail.com>
Message-ID: <CAE=-AhBUN-2DaAp0YR3qUzDBeZogUFQp9o+xm43nd8d=JAvfSQ@mail.gmail.com>

Hi,

On Saturday, July 4, 2015, Antoine Sabot-Durand <antoine at sabot-durand.net>
wrote:

> Candi implements CDI 1.0 and never provided solution for java SE. To my
> knowledge that don't have plan for CDI 1.2 or 2.0.


I noticed that Resin (which uses CanDI as its CDI implementation) is still
active. I would assume that eventually they'll want to move to EE 7 and not
stay on EE 6 "forever". But I'll ask in the Resin mailing group.

Anyway, maybe the sentence would be a little more correct if it was
something like:

"Since the beginning two of the three early implementations (JBoss Weld and
Apache OpenWebBeans) proposed proprietary solutions to use CDI in Java SE."

Kind regards,
Arjan Tijms





>
> Antoine
> Le sam. 4 juil. 2015 ? 14:02, arjan tijms <arjan.tijms at gmail.com> a
> ?crit :
>
>> Hi,
>>
>> I've got one comment:
>>
>> >Since the beginning both implementations (JBoss Weld and Apache
>> OpenWebBeans) proposed proprietary solutions to use CDI in Java SE.
>>
>> Aren't there 3 implementations really? CanDI implements CDI too, doesn't
>> it?
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>> On Fri, Jul 3, 2015 at 4:17 PM, Antoine Sabot-Durand
>> <antoine at sabot-durand.net> wrote:
>> > Of course it's CDI 2.0 EDR1 ;). <bad faith>it was a test to see if
>> someone
>> > was actually reading </bad faith>
>> >
>> > Antoine
>> >
>> > Le 3 juil. 2015 ? 15:41, John D. Ament <john.d.ament at gmail.com> a
>> ?crit :
>> >
>> > Very nice! (though the email subject is a little misleading)
>> >
>> > On Fri, Jul 3, 2015 at 9:12 AM Antoine Sabot-Durand
>> > <antoine at sabot-durand.net> wrote:
>> >>
>> >> Hi guys,
>> >>
>> >>
>> >> You can communicate on it or give me your feedback on the post
>> >>
>> >> http://cdi-spec.org/news/2015/07/03/CDI-2_0-EDR1-released/
>> >>
>> >> Antoine
>> >> _______________________________________________
>> >> 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150704/f2030bbd/attachment-0001.html 

From antoine at sabot-durand.net  Mon Jul  6 04:20:02 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 06 Jul 2015 08:20:02 +0000
Subject: [cdi-dev] Who will attend tomorrow's meeting?
Message-ID: <CABu-YBQcokb6ReTJgJGvF8J9y4vtmV40T0jRh36aCQcN=U74rQ@mail.gmail.com>

Hi
Let me know if you'll be there tomorrow for our irc meeting
Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150706/cadc800d/attachment.html 

From thjanssen123 at gmail.com  Mon Jul  6 05:19:50 2015
From: thjanssen123 at gmail.com (Thorben Janssen)
Date: Mon, 6 Jul 2015 11:19:50 +0200
Subject: [cdi-dev] Who will attend tomorrow's meeting?
In-Reply-To: <CABu-YBQcokb6ReTJgJGvF8J9y4vtmV40T0jRh36aCQcN=U74rQ@mail.gmail.com>
References: <CABu-YBQcokb6ReTJgJGvF8J9y4vtmV40T0jRh36aCQcN=U74rQ@mail.gmail.com>
Message-ID: <CAE9nDy-QsbhjxLu3GpPjp+TafV4bniwnDbgbPXaf6PMVGw0CSQ@mail.gmail.com>

Hi Antoine,

I'll most probably be there.

Regards,
Thorben

--
*Thorben Janssen*

@thjanssen123 <https://twitter.com/thjanssen123>
www.thoughts-on-java.org

2015-07-06 10:20 GMT+02:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

> Hi
> Let me know if you'll be there tomorrow for our irc meeting
> Antoine
>
> _______________________________________________
> 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/20150706/966337b7/attachment.html 

From antoine at sabot-durand.net  Mon Jul  6 10:10:42 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 06 Jul 2015 14:10:42 +0000
Subject: [cdi-dev] Tomorrow's meeting agenda
Message-ID: <CABu-YBRWuh-q77uqtOTA+qvG+zSojK_ZJnBzMSyXoYfnK+m8VQ@mail.gmail.com>

Hi All,

I propose the following agenda for tomorrow:

1) Launch AOP workshop:
- AOP support on custom beans
- AOP support on producers
- Self Injection or AOP activated when method called from inside beans
- Decorators without Interface
2) Finishing SE part
- Context control in SE (CDI 530)
- Bean Discovery in SE (CDI 529)
3) Discuss quick win tickets (if we have time)

If you have suggestion or point you'd like to add. Feel free to raise your
hand.

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150706/410c19ee/attachment.html 

From antoine at sabot-durand.net  Mon Jul  6 12:28:05 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 06 Jul 2015 16:28:05 +0000
Subject: [cdi-dev] CDI 2.0 release is official
In-Reply-To: <CAE=-AhBUN-2DaAp0YR3qUzDBeZogUFQp9o+xm43nd8d=JAvfSQ@mail.gmail.com>
References: <6AB1D754-CA47-4558-81BB-ED03A8CFD95A@sabot-durand.net>
	<CAOqetn_NMDZWQ+V9WJJpUf9uFVgcGcp1ghXM6NvAz8Xdqy+A0w@mail.gmail.com>
	<F80938F0-F88B-4071-8BCD-FD1D82363002@sabot-durand.net>
	<CAE=-AhAbTK_dm007tFWEQb-NEbb8ryaOfrqm4h3d2USr+wxJww@mail.gmail.com>
	<CABu-YBTyb35uWyjqDN90nuRax5gp=u3mu3L-a1_bNvyy7eBbfA@mail.gmail.com>
	<CAE=-AhBUN-2DaAp0YR3qUzDBeZogUFQp9o+xm43nd8d=JAvfSQ@mail.gmail.com>
Message-ID: <CABu-YBS0_FHTHtF+9UaJR=0CPSRWzNtPZnp8wAOmB7_ncFm=Dg@mail.gmail.com>

Arjan,

I posted an message on their forum two years ago to know their plan for CDI
1.1 support. Still waiting for the answer... I changed the sentence in "the
two main implementations".

Antoine

Le sam. 4 juil. 2015 ? 20:15, arjan tijms <arjan.tijms at gmail.com> a ?crit :

> Hi,
>
>
> On Saturday, July 4, 2015, Antoine Sabot-Durand <antoine at sabot-durand.net>
> wrote:
>
>> Candi implements CDI 1.0 and never provided solution for java SE. To my
>> knowledge that don't have plan for CDI 1.2 or 2.0.
>
>
> I noticed that Resin (which uses CanDI as its CDI implementation) is still
> active. I would assume that eventually they'll want to move to EE 7 and not
> stay on EE 6 "forever". But I'll ask in the Resin mailing group.
>
> Anyway, maybe the sentence would be a little more correct if it was
> something like:
>
> "Since the beginning two of the three early implementations (JBoss Weld
> and Apache OpenWebBeans) proposed proprietary solutions to use CDI in Java
> SE."
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>>
>> Antoine
>> Le sam. 4 juil. 2015 ? 14:02, arjan tijms <arjan.tijms at gmail.com> a
>> ?crit :
>>
>>> Hi,
>>>
>>> I've got one comment:
>>>
>>> >Since the beginning both implementations (JBoss Weld and Apache
>>> OpenWebBeans) proposed proprietary solutions to use CDI in Java SE.
>>>
>>> Aren't there 3 implementations really? CanDI implements CDI too, doesn't
>>> it?
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>> On Fri, Jul 3, 2015 at 4:17 PM, Antoine Sabot-Durand
>>> <antoine at sabot-durand.net> wrote:
>>> > Of course it's CDI 2.0 EDR1 ;). <bad faith>it was a test to see if
>>> someone
>>> > was actually reading </bad faith>
>>> >
>>> > Antoine
>>> >
>>> > Le 3 juil. 2015 ? 15:41, John D. Ament <john.d.ament at gmail.com> a
>>> ?crit :
>>> >
>>> > Very nice! (though the email subject is a little misleading)
>>> >
>>> > On Fri, Jul 3, 2015 at 9:12 AM Antoine Sabot-Durand
>>> > <antoine at sabot-durand.net> wrote:
>>> >>
>>> >> Hi guys,
>>> >>
>>> >>
>>> >> You can communicate on it or give me your feedback on the post
>>> >>
>>> >> http://cdi-spec.org/news/2015/07/03/CDI-2_0-EDR1-released/
>>> >>
>>> >> Antoine
>>> >> _______________________________________________
>>> >> 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.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150706/be2116ce/attachment.html 

From issues at jboss.org  Mon Jul  6 19:12:01 2015
From: issues at jboss.org (Dhiraj Dwarapudi (JIRA))
Date: Mon, 6 Jul 2015 19:12:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
In-Reply-To: <JIRA.12577150.1436224262000@Atlassian.JIRA>
References: <JIRA.12577150.1436224262000@Atlassian.JIRA>
	<JIRA.12577150.1436224262023@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577150.1436224262000.103326.1436224321948@Atlassian.JIRA>

Dhiraj Dwarapudi created CDI-539:
------------------------------------

             Summary: Support for 'profile' in CDI
                 Key: CDI-539
                 URL: https://issues.jboss.org/browse/CDI-539
             Project: CDI Specification Issues
          Issue Type: Feature Request
          Components: Contexts
            Reporter: Dhiraj Dwarapudi


I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.

Spring has a nice support for this with the concept of a 'Profile':
https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/

Would be really helpful if CDI has support for this. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Mon Jul  6 20:16:03 2015
From: issues at jboss.org (George Gastaldi (JIRA))
Date: Mon, 6 Jul 2015 20:16:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
In-Reply-To: <JIRA.12577150.1436224262000@Atlassian.JIRA>
References: <JIRA.12577150.1436224262000@Atlassian.JIRA>
	<JIRA.12577150.1436224262000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577150.1436224262000.103430.1436228163194@Atlassian.JIRA>


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

George Gastaldi commented on CDI-539:
-------------------------------------

This is very interesting. I wonder if there is enough room to fit in the CDI 2.0 schedule or should it be postponed to the next spec version? [~antoinesabot-durand]?

> Support for 'profile' in CDI
> ----------------------------
>
>                 Key: CDI-539
>                 URL: https://issues.jboss.org/browse/CDI-539
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts
>            Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Jul  7 03:59:02 2015
From: issues at jboss.org (Sven Linstaedt (JIRA))
Date: Tue, 7 Jul 2015 03:59:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
In-Reply-To: <JIRA.12577150.1436224262000@Atlassian.JIRA>
References: <JIRA.12577150.1436224262000@Atlassian.JIRA>
	<JIRA.12577150.1436224262000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577150.1436224262000.103934.1436255942682@Atlassian.JIRA>


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

Sven Linstaedt commented on CDI-539:
------------------------------------

Something like Deltaspike's [ProjectStage|https://deltaspike.apache.org/documentation/projectstage.html]?

> Support for 'profile' in CDI
> ----------------------------
>
>                 Key: CDI-539
>                 URL: https://issues.jboss.org/browse/CDI-539
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts
>            Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From sven.linstaedt at gmail.com  Tue Jul  7 03:59:03 2015
From: sven.linstaedt at gmail.com (Sven Linstaedt)
Date: Tue, 7 Jul 2015 09:59:03 +0200
Subject: [cdi-dev] Tomorrow's meeting agenda
In-Reply-To: <CABu-YBRWuh-q77uqtOTA+qvG+zSojK_ZJnBzMSyXoYfnK+m8VQ@mail.gmail.com>
References: <CABu-YBRWuh-q77uqtOTA+qvG+zSojK_ZJnBzMSyXoYfnK+m8VQ@mail.gmail.com>
Message-ID: <CADDZ-ccF9tqxqu0twhMRvPj1pe0eE0UA8A5s5q+-fBjf1A=nqw@mail.gmail.com>

Hi,

regarding 3)

is there an actual list of quick-win tickets or do you have any in mind?


br, Sven

2015-07-06 16:10 GMT+02:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

> Hi All,
>
> I propose the following agenda for tomorrow:
>
> 1) Launch AOP workshop:
> - AOP support on custom beans
> - AOP support on producers
> - Self Injection or AOP activated when method called from inside beans
> - Decorators without Interface
> 2) Finishing SE part
> - Context control in SE (CDI 530)
> - Bean Discovery in SE (CDI 529)
> 3) Discuss quick win tickets (if we have time)
>
> If you have suggestion or point you'd like to add. Feel free to raise your
> hand.
>
> Antoine
>
> _______________________________________________
> 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/20150707/ad734424/attachment.html 

From werner.keil at gmail.com  Tue Jul  7 04:07:14 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Tue, 7 Jul 2015 10:07:14 +0200
Subject: [cdi-dev] Who will attend tomorrow's meeting?
Message-ID: <CAAGawe2dK_8jwQ_XveN6s6TaeOKZHrq-WPW6Med8gRgeGunhaQ@mail.gmail.com>

As I need to attend the monthly EC call, I probably won't make it.

Werner

On Tue, Jul 7, 2015 at 9:59 AM, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
>         cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
>    1. Who will attend tomorrow's meeting? (Antoine Sabot-Durand)
>    2. Re: Who will attend tomorrow's meeting? (Thorben Janssen)
>    3. Tomorrow's meeting agenda (Antoine Sabot-Durand)
>    4. Re: CDI 2.0 release is official (Antoine Sabot-Durand)
>    5. [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
>       (Dhiraj Dwarapudi (JIRA))
>    6. [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
>       (George Gastaldi (JIRA))
>    7. [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
>       (Sven Linstaedt (JIRA))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 06 Jul 2015 08:20:02 +0000
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: [cdi-dev] Who will attend tomorrow's meeting?
> To: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CABu-YBQcokb6ReTJgJGvF8J9y4vtmV40T0jRh36aCQcN=
> U74rQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi
> Let me know if you'll be there tomorrow for our irc meeting
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150706/cadc800d/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Mon, 6 Jul 2015 11:19:50 +0200
> From: Thorben Janssen <thjanssen123 at gmail.com>
> Subject: Re: [cdi-dev] Who will attend tomorrow's meeting?
> To: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CAE9nDy-QsbhjxLu3GpPjp+TafV4bniwnDbgbPXaf6PMVGw0CSQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Antoine,
>
> I'll most probably be there.
>
> Regards,
> Thorben
>
> --
> *Thorben Janssen*
>
> @thjanssen123 <https://twitter.com/thjanssen123>
> www.thoughts-on-java.org
>
> 2015-07-06 10:20 GMT+02:00 Antoine Sabot-Durand <antoine at sabot-durand.net
> >:
>
> > Hi
> > Let me know if you'll be there tomorrow for our irc meeting
> > Antoine
> >
> > _______________________________________________
> > 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/20150706/966337b7/attachment-0001.html
>
>
>
> ------------------------------
>
> _______________________________________________
> 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.
>
> End of cdi-dev Digest, Vol 56, Issue 3
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150707/69a968bc/attachment.html 

From issues at jboss.org  Tue Jul  7 08:17:05 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 7 Jul 2015 08:17:05 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-438) Fix type parameters ordering in
 ProcessProducerMethod and ProcessProducerField events
In-Reply-To: <JIRA.12540105.1399467093000@Atlassian.JIRA>
References: <JIRA.12540105.1399467093000@Atlassian.JIRA>
	<JIRA.12540105.1399467093000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540105.1399467093000.105123.1436271425064@Atlassian.JIRA>


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

Martin Kouba commented on CDI-438:
----------------------------------

{quote}
With this change done, is there still any reason to prevent delivering of ProcessProducerMethod<Foo,Producer> to observer of ProcessBean<Foo>? I think it could make sense in certain use cases...
{quote}
Yes, I think so. For a producer method like this:
{code}
class Producer {
  Foo produce() {
    return new Foo();
  }
}
{code}
The event types include {{ProcessProducerMethod<Foo,Producer>}}, {{ProcessBean<Producer>}} and {{Object}}. And none of these types is assignable to {{ProcessBean<Foo>}}.

To be honest I'm not quite sure whether it would be better to observe the return type or the bean class (current wording) for producer methods/fields. But if I understand your previous comment correctly we can't fix this anyway...

We should also fix the {{javax.enterprise.inject.spi.ProcessBean}} javadoc:
{quote}
...
For a producer method with method return type X of a bean with bean class T, the container must raise an event of type javax.enterprise.inject.spi.ProcessProducerMethod<T, X>.
...
{quote}

> Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events
> -------------------------------------------------------------------------------------
>
>                 Key: CDI-438
>                 URL: https://issues.jboss.org/browse/CDI-438
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0-EDR1
>
>
> Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event...
> The text:
> {quote}
> For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod<T, X>.
> {quote}
> API:
> {code:java}
> /**
>  * @param <T> The return type of the producer method
>  * @param <X> The class of the bean declaring the producer method
>  */
> public interface ProcessProducerMethod<T, X> extends ProcessBean<X> {
> }
> {code}
> The same applies to {{ProcessProducerField}}. 
> TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod<Foo,Producer>}} event is not delivered to an observer with the event parameter {{ProcessBean<Foo>}} - which is required by the spec but does not make sense at the same time.
> It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From slaskawi at redhat.com  Tue Jul  7 08:18:44 2015
From: slaskawi at redhat.com (=?UTF-8?Q?Sebastian_=c5=81askawiec?=)
Date: Tue, 7 Jul 2015 14:18:44 +0200
Subject: [cdi-dev] Constructor dependency
Message-ID: <559BC3A4.2080101@redhat.com>

Hey!

I've seen CDI 2.0 Early Draft - congratulations! Looks very promising!

I would like to ask about something slightly different than CDI 2.0 - 
constructor injection. I'm a big fan of using it because I can easily 
inject mocks into tested objects. This way I can limit the number of 
Arquillian tests and speed up testing phase in my project.

However the drawback is that need 2 constructors in my beans:

@ApplicationScoped
public class MyBean {
     public MyBean() {
     }

     @Inject
     public MyBean(OtherBean bean) {
     }
}

Is it possible to get rid of the zero-parameter constructor? I can 
imagine that it may be required by dependency resolution mechanism (for 
example instantiating beans with cyclic dependencies A -> B -> C -> A), 
but on the other hand we actually can create an instance without calling 
a constructor - using Unsafe (but using Unsafe is always questionable).

Could you please tell me if there are any plans around this topic?

Thanks
Sebastian

From mkouba at redhat.com  Tue Jul  7 08:26:18 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 07 Jul 2015 14:26:18 +0200
Subject: [cdi-dev] Constructor dependency
In-Reply-To: <559BC3A4.2080101@redhat.com>
References: <559BC3A4.2080101@redhat.com>
Message-ID: <559BC56A.6050907@redhat.com>

Hi Sebastian,

the "superfluous" constructor is required for client proxies (i.e. for 
normal-scoped beans). Weld may use non-portable JVM APIs that allow to 
allocate proxy instances without this constructor (Unsafe). The feature 
is called "Relaxed construction" [1]. Again, this feature is not portable.

Martin

[1]
http://docs.jboss.org/weld/reference/latest/en-US/html/configure.html#relaxedConstruction

Dne 7.7.2015 v 14:18 Sebastian ?askawiec napsal(a):
> Hey!
>
> I've seen CDI 2.0 Early Draft - congratulations! Looks very promising!
>
> I would like to ask about something slightly different than CDI 2.0 -
> constructor injection. I'm a big fan of using it because I can easily
> inject mocks into tested objects. This way I can limit the number of
> Arquillian tests and speed up testing phase in my project.
>
> However the drawback is that need 2 constructors in my beans:
>
> @ApplicationScoped
> public class MyBean {
>       public MyBean() {
>       }
>
>       @Inject
>       public MyBean(OtherBean bean) {
>       }
> }
>
> Is it possible to get rid of the zero-parameter constructor? I can
> imagine that it may be required by dependency resolution mechanism (for
> example instantiating beans with cyclic dependencies A -> B -> C -> A),
> but on the other hand we actually can create an instance without calling
> a constructor - using Unsafe (but using Unsafe is always questionable).
>
> Could you please tell me if there are any plans around this topic?
>
> Thanks
> Sebastian
> _______________________________________________
> 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
Software Engineer
Red Hat, Czech Republic

From slaskawi at redhat.com  Tue Jul  7 10:08:50 2015
From: slaskawi at redhat.com (=?UTF-8?Q?Sebastian_=c5=81askawiec?=)
Date: Tue, 7 Jul 2015 16:08:50 +0200
Subject: [cdi-dev] Constructor dependency
In-Reply-To: <559BC56A.6050907@redhat.com>
References: <559BC3A4.2080101@redhat.com> <559BC56A.6050907@redhat.com>
Message-ID: <559BDD72.3030808@redhat.com>

Thanks Martin for the explanation!

Are there any plans to propagate this behavior to the spec?

Thanks
Sebastian

On 07/07/2015 02:26 PM, Martin Kouba wrote:
> Hi Sebastian,
>
> the "superfluous" constructor is required for client proxies (i.e. for 
> normal-scoped beans). Weld may use non-portable JVM APIs that allow to 
> allocate proxy instances without this constructor (Unsafe). The 
> feature is called "Relaxed construction" [1]. Again, this feature is 
> not portable.
>
> Martin
>
> [1]
> http://docs.jboss.org/weld/reference/latest/en-US/html/configure.html#relaxedConstruction 
>
>
> Dne 7.7.2015 v 14:18 Sebastian ?askawiec napsal(a):
>> Hey!
>>
>> I've seen CDI 2.0 Early Draft - congratulations! Looks very promising!
>>
>> I would like to ask about something slightly different than CDI 2.0 -
>> constructor injection. I'm a big fan of using it because I can easily
>> inject mocks into tested objects. This way I can limit the number of
>> Arquillian tests and speed up testing phase in my project.
>>
>> However the drawback is that need 2 constructors in my beans:
>>
>> @ApplicationScoped
>> public class MyBean {
>>       public MyBean() {
>>       }
>>
>>       @Inject
>>       public MyBean(OtherBean bean) {
>>       }
>> }
>>
>> Is it possible to get rid of the zero-parameter constructor? I can
>> imagine that it may be required by dependency resolution mechanism (for
>> example instantiating beans with cyclic dependencies A -> B -> C -> A),
>> but on the other hand we actually can create an instance without calling
>> a constructor - using Unsafe (but using Unsafe is always questionable).
>>
>> Could you please tell me if there are any plans around this topic?
>>
>> Thanks
>> Sebastian
>> _______________________________________________
>> 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 rmannibucau at gmail.com  Tue Jul  7 10:57:11 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 7 Jul 2015 16:57:11 +0200
Subject: [cdi-dev] Constructor dependency
In-Reply-To: <559BDD72.3030808@redhat.com>
References: <559BC3A4.2080101@redhat.com> <559BC56A.6050907@redhat.com>
	<559BDD72.3030808@redhat.com>
Message-ID: <CACLE=7MmeOxYg1A-xxaQo4PwQe3DCVwMNBbT5g+S+p2KEEPoiQ@mail.gmail.com>

Hi

I d love to have it portable as well and dont really see a big blocker
technically.

It wouldnt break backward compatibility in practise.
 Le 7 juil. 2015 07:09, "Sebastian ?askawiec" <slaskawi at redhat.com> a
?crit :

> Thanks Martin for the explanation!
>
> Are there any plans to propagate this behavior to the spec?
>
> Thanks
> Sebastian
>
> On 07/07/2015 02:26 PM, Martin Kouba wrote:
> > Hi Sebastian,
> >
> > the "superfluous" constructor is required for client proxies (i.e. for
> > normal-scoped beans). Weld may use non-portable JVM APIs that allow to
> > allocate proxy instances without this constructor (Unsafe). The
> > feature is called "Relaxed construction" [1]. Again, this feature is
> > not portable.
> >
> > Martin
> >
> > [1]
> >
> http://docs.jboss.org/weld/reference/latest/en-US/html/configure.html#relaxedConstruction
> >
> >
> > Dne 7.7.2015 v 14:18 Sebastian ?askawiec napsal(a):
> >> Hey!
> >>
> >> I've seen CDI 2.0 Early Draft - congratulations! Looks very promising!
> >>
> >> I would like to ask about something slightly different than CDI 2.0 -
> >> constructor injection. I'm a big fan of using it because I can easily
> >> inject mocks into tested objects. This way I can limit the number of
> >> Arquillian tests and speed up testing phase in my project.
> >>
> >> However the drawback is that need 2 constructors in my beans:
> >>
> >> @ApplicationScoped
> >> public class MyBean {
> >>       public MyBean() {
> >>       }
> >>
> >>       @Inject
> >>       public MyBean(OtherBean bean) {
> >>       }
> >> }
> >>
> >> Is it possible to get rid of the zero-parameter constructor? I can
> >> imagine that it may be required by dependency resolution mechanism (for
> >> example instantiating beans with cyclic dependencies A -> B -> C -> A),
> >> but on the other hand we actually can create an instance without calling
> >> a constructor - using Unsafe (but using Unsafe is always questionable).
> >>
> >> Could you please tell me if there are any plans around this topic?
> >>
> >> Thanks
> >> Sebastian
> >> _______________________________________________
> >> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150707/e24c8d81/attachment.html 

From issues at jboss.org  Tue Jul  7 15:04:02 2015
From: issues at jboss.org (Dhiraj Dwarapudi (JIRA))
Date: Tue, 7 Jul 2015 15:04:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
In-Reply-To: <JIRA.12577150.1436224262000@Atlassian.JIRA>
References: <JIRA.12577150.1436224262000@Atlassian.JIRA>
	<JIRA.12577150.1436224262000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577150.1436224262000.106811.1436295842614@Atlassian.JIRA>


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

Dhiraj Dwarapudi commented on CDI-539:
--------------------------------------

[~tzwoenn]
Yeah, something similar to ProjectStage. 

But 'profile' is more usable and covers larger use cases. 
* I can have mutliple profiles active at the same time
* I would like to boootstrap my application at start-time with different profiles. ProjectStage can be used to accomplish this, but the intent of ProjectStage (as the name suggests) seem to be more for different stages of application development
* The way 'profile's are implemented in Spring, a custom profile is just another string. So you don't need to write any code to support custom 'profile'. For that matter there are not built-in profiles. They are user-defined.


> Support for 'profile' in CDI
> ----------------------------
>
>                 Key: CDI-539
>                 URL: https://issues.jboss.org/browse/CDI-539
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts
>            Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul  8 09:14:02 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 8 Jul 2015 09:14:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-540) Clarify
	CDIProvider.isInitialized() javadoc
In-Reply-To: <JIRA.12577395.1436361193000@Atlassian.JIRA>
References: <JIRA.12577395.1436361193000@Atlassian.JIRA>
	<JIRA.12577395.1436361193272@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577395.1436361193000.108860.1436361242232@Atlassian.JIRA>

Martin Kouba created CDI-540:
--------------------------------

             Summary: Clarify CDIProvider.isInitialized() javadoc
                 Key: CDI-540
                 URL: https://issues.jboss.org/browse/CDI-540
             Project: CDI Specification Issues
          Issue Type: Clarification
    Affects Versions: 2.0-EDR1
            Reporter: Martin Kouba


I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Jul  9 07:53:03 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 9 Jul 2015 07:53:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
In-Reply-To: <JIRA.12577150.1436224262000@Atlassian.JIRA>
References: <JIRA.12577150.1436224262000@Atlassian.JIRA>
	<JIRA.12577150.1436224262000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577150.1436224262000.110983.1436442783152@Atlassian.JIRA>


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

Jozef Hartinger commented on CDI-539:
-------------------------------------

This is exactly what @Alternative @Stereotypes are for in CDI. You can create your own "profiles" by introducing a stereotype annotated with @Alternative, e.g. @Mock, @Production etc. You can then activate the stereotypes you want active in beans.xml. This concept should be extended in CDI 2.0 to work with @Priority and CDI extensions.

> Support for 'profile' in CDI
> ----------------------------
>
>                 Key: CDI-539
>                 URL: https://issues.jboss.org/browse/CDI-539
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts
>            Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Jul  9 08:26:03 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 9 Jul 2015 08:26:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
In-Reply-To: <JIRA.12577150.1436224262000@Atlassian.JIRA>
References: <JIRA.12577150.1436224262000@Atlassian.JIRA>
	<JIRA.12577150.1436224262000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577150.1436224262000.111045.1436444763055@Atlassian.JIRA>


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

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

Agree with Jozef but I may have missed something. [~gastaldi]: What is missing in your opinion in @Alternatives activated via @Stereotypes to provide this feature? [~jharting] what do you suggest to improve this in CDI 2.0?

> Support for 'profile' in CDI
> ----------------------------
>
>                 Key: CDI-539
>                 URL: https://issues.jboss.org/browse/CDI-539
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts
>            Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Jul  9 09:44:03 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 9 Jul 2015 09:44:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
In-Reply-To: <JIRA.12577150.1436224262000@Atlassian.JIRA>
References: <JIRA.12577150.1436224262000@Atlassian.JIRA>
	<JIRA.12577150.1436224262000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577150.1436224262000.111457.1436449443677@Atlassian.JIRA>


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

Jozef Hartinger commented on CDI-539:
-------------------------------------

The missing part is global activation of @Alternative @Stereotypes with @Priority or using an extension. The latter is supported by Weld but it is not portable.

> Support for 'profile' in CDI
> ----------------------------
>
>                 Key: CDI-539
>                 URL: https://issues.jboss.org/browse/CDI-539
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts
>            Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Jul  9 09:49:03 2015
From: issues at jboss.org (George Gastaldi (JIRA))
Date: Thu, 9 Jul 2015 09:49:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
In-Reply-To: <JIRA.12577150.1436224262000@Atlassian.JIRA>
References: <JIRA.12577150.1436224262000@Atlassian.JIRA>
	<JIRA.12577150.1436224262000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577150.1436224262000.111514.1436449743584@Atlassian.JIRA>


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

George Gastaldi commented on CDI-539:
-------------------------------------

I agree that @Alternatives and @Stereotypes can solve the problem, but I guess the idea here is to activate them using a system property or something like it. Activating alternatives in beans.xml would require changes to the XML, and I suppose that's what this issue is about, or maybe Dhiraj can elaborate a bit more?

> Support for 'profile' in CDI
> ----------------------------
>
>                 Key: CDI-539
>                 URL: https://issues.jboss.org/browse/CDI-539
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts
>            Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Jul  9 11:27:04 2015
From: issues at jboss.org (Dhiraj Dwarapudi (JIRA))
Date: Thu, 9 Jul 2015 11:27:04 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
In-Reply-To: <JIRA.12577150.1436224262000@Atlassian.JIRA>
References: <JIRA.12577150.1436224262000@Atlassian.JIRA>
	<JIRA.12577150.1436224262000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577150.1436224262000.111778.1436455624125@Atlassian.JIRA>


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

Dhiraj Dwarapudi commented on CDI-539:
--------------------------------------

Yeah, I was looking at activating them using a System property instead of modifying the xml. 

> Support for 'profile' in CDI
> ----------------------------
>
>                 Key: CDI-539
>                 URL: https://issues.jboss.org/browse/CDI-539
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts
>            Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 10 02:19:03 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Fri, 10 Jul 2015 02:19:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
In-Reply-To: <JIRA.12577150.1436224262000@Atlassian.JIRA>
References: <JIRA.12577150.1436224262000@Atlassian.JIRA>
	<JIRA.12577150.1436224262000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577150.1436224262000.112655.1436509143269@Atlassian.JIRA>


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

Mark Struberg commented on CDI-539:
-----------------------------------

> global activation of @Alternative @Stereotypes with @Priority or using an extension.
In OpenWebBeans they are globally enabled per ee module by default, even without @Priority.

I think the question was more about WHEN to activate those Alternatives and @Specializes. We did discuss the ProjectStage in the past and the conclusio was that this is nothing which CDI should define but it's an EE umbrella wide topic.

> Support for 'profile' in CDI
> ----------------------------
>
>                 Key: CDI-539
>                 URL: https://issues.jboss.org/browse/CDI-539
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts
>            Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 10 02:20:03 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Fri, 10 Jul 2015 02:20:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-539) Support for 'profile' in CDI
In-Reply-To: <JIRA.12577150.1436224262000@Atlassian.JIRA>
References: <JIRA.12577150.1436224262000@Atlassian.JIRA>
	<JIRA.12577150.1436224262000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577150.1436224262000.112663.1436509203783@Atlassian.JIRA>


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

Mark Struberg edited comment on CDI-539 at 7/10/15 2:19 AM:
------------------------------------------------------------

> global activation of @Alternative @Stereotypes with @Priority or using an extension.
In OpenWebBeans they are globally enabled per ee module by default, even without @Priority.

I think the question was more about WHEN to activate those Alternatives and @Specializes. We did discuss the ProjectStage in the past and the conclusio was that this is nothing which CDI should define but it's an EE umbrella wide topic.

Similar topic is true for enable it on a config base. This would need a configuration JSR first (kind of DeltaSpikes ConfigResolver but even more generic). But this got turned down so far for JavaEE8 by Oracle.


was (Author: struberg):
> global activation of @Alternative @Stereotypes with @Priority or using an extension.
In OpenWebBeans they are globally enabled per ee module by default, even without @Priority.

I think the question was more about WHEN to activate those Alternatives and @Specializes. We did discuss the ProjectStage in the past and the conclusio was that this is nothing which CDI should define but it's an EE umbrella wide topic.

> Support for 'profile' in CDI
> ----------------------------
>
>                 Key: CDI-539
>                 URL: https://issues.jboss.org/browse/CDI-539
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts
>            Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From mkouba at redhat.com  Mon Jul 13 07:03:29 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 13 Jul 2015 13:03:29 +0200
Subject: [cdi-dev] FireAsyncException question
Message-ID: <55A39B01.10109@redhat.com>

Hi all,

the CDI 2.0 EDR1, "10.5.1. Handling multiple exceptions thrown during an 
asynchronous event" currently states:

"If an event is asynchronous, and an exception is thrown by any of its 
notified observers, the CompletionStage returned by fireAsync will 
complete exceptionally with FireAsyncException exception."

And there's also an example of handle() method with lambda which gets 
FireAsyncException passed as an param. This looks good from the user 
point of view.

However, what should happen if I use e.g. thenAccept() method? The 
CompletionStage API is clear:
"Two method forms support processing whether the triggering... In all 
other cases, if a stage's computation terminates abruptly with an 
(unchecked) exception or error, then all dependent stages requiring its 
completion complete exceptionally as well, with a CompletionException 
holding the exception as its cause...". In other words, 
myEvent.fireAsync(...).thenAccept(...).exceptionally(...) should receive 
CompletionException and not FireAsyncException.

This seems a bit inconsistent to me. Am I missing something?

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From antoine at sabot-durand.net  Mon Jul 13 08:14:23 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 13 Jul 2015 12:14:23 +0000
Subject: [cdi-dev] Relaunching discussion around visibility and isolation
Message-ID: <CABu-YBS7V3Z_P6+eG3xb=CyenAkbk-tb3myVUk-tpk6Qm9E3AA@mail.gmail.com>

Hi All,

CDI-129 (https://issues.jboss.org/browse/CDI-129) is one of the most
discussed tickets. To sum up all the discussion, main subjects dealt in
this ticket are
- Visibility of beans in an EAR
- Isolation of extensions

The goal here is to set rules at spec level for @ApplicationScoped beans in
EAR (war or jar).
I discussed with Mark Struberg last week and he should provide us a
synthesis on the topic in the coming days.

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

From antoine at sabot-durand.net  Mon Jul 13 08:36:50 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 13 Jul 2015 12:36:50 +0000
Subject: [cdi-dev] FireAsyncException question
In-Reply-To: <55A39B01.10109@redhat.com>
References: <55A39B01.10109@redhat.com>
Message-ID: <CABu-YBR16z8xTBJxVWgdfHNjiv37g_g0uYvx+8Z91T802K0Pdg@mail.gmail.com>

Good question Martin,

We added the FireAsyncException because users don't have hook on the
pipeline created internally by the vent dispatcher. If you call hand or
whenComplete on the completionStage returned by fireAsync() you'll get the
FireAsyncException.
If you choose to continue the pipeline without checking the outcome of
fireAsync you'll get the CompletionException wrapping the
FireAsyncException.

Now if you have suggestion to handle this differently, your input is
welcome. The EDR is here for that ;).

Antoine

Le lun. 13 juil. 2015 ? 13:04, Martin Kouba <mkouba at redhat.com> a ?crit :

> Hi all,
>
> the CDI 2.0 EDR1, "10.5.1. Handling multiple exceptions thrown during an
> asynchronous event" currently states:
>
> "If an event is asynchronous, and an exception is thrown by any of its
> notified observers, the CompletionStage returned by fireAsync will
> complete exceptionally with FireAsyncException exception."
>
> And there's also an example of handle() method with lambda which gets
> FireAsyncException passed as an param. This looks good from the user
> point of view.
>
> However, what should happen if I use e.g. thenAccept() method? The
> CompletionStage API is clear:
> "Two method forms support processing whether the triggering... In all
> other cases, if a stage's computation terminates abruptly with an
> (unchecked) exception or error, then all dependent stages requiring its
> completion complete exceptionally as well, with a CompletionException
> holding the exception as its cause...". In other words,
> myEvent.fireAsync(...).thenAccept(...).exceptionally(...) should receive
> CompletionException and not FireAsyncException.
>
> This seems a bit inconsistent to me. Am I missing something?
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> 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/20150713/cd95d0aa/attachment.html 

From antoine at sabot-durand.net  Mon Jul 13 17:11:17 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 13 Jul 2015 21:11:17 +0000
Subject: [cdi-dev] No meeting tomorrow
Message-ID: <CABu-YBSrSrfvAPt_PLtiZvsW0d62W4Os=fb3pVYgKJ-_WDh5JA@mail.gmail.com>

Hi Guys,

I'm on PTO tomorrow (it's Bastille Day) so no meetings.

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150713/1875fedd/attachment.html 

From john.d.ament at gmail.com  Mon Jul 13 18:30:33 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Mon, 13 Jul 2015 22:30:33 +0000
Subject: [cdi-dev] No meeting tomorrow
In-Reply-To: <CABu-YBSrSrfvAPt_PLtiZvsW0d62W4Os=fb3pVYgKJ-_WDh5JA@mail.gmail.com>
References: <CABu-YBSrSrfvAPt_PLtiZvsW0d62W4Os=fb3pVYgKJ-_WDh5JA@mail.gmail.com>
Message-ID: <CAOqetn9O--NUp-UbCx5OsEhy4bzpc3Yrm3UMnin=HzQ1Ny02xA@mail.gmail.com>

bom dia!

(just got done telling new project manager no Tuesday meetings for this one)

John

On Mon, Jul 13, 2015 at 5:12 PM Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> Hi Guys,
>
> I'm on PTO tomorrow (it's Bastille Day) so no meetings.
>
> Antoine
> _______________________________________________
> 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/20150713/4ab125ea/attachment-0001.html 

From antoine at sabot-durand.net  Tue Jul 14 00:38:24 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 14 Jul 2015 04:38:24 +0000
Subject: [cdi-dev] No meeting tomorrow
In-Reply-To: <CAOqetn9O--NUp-UbCx5OsEhy4bzpc3Yrm3UMnin=HzQ1Ny02xA@mail.gmail.com>
References: <CABu-YBSrSrfvAPt_PLtiZvsW0d62W4Os=fb3pVYgKJ-_WDh5JA@mail.gmail.com>
	<CAOqetn9O--NUp-UbCx5OsEhy4bzpc3Yrm3UMnin=HzQ1Ny02xA@mail.gmail.com>
Message-ID: <CABu-YBQfphog5jkAgTnt5h1MOmSv769G7nmsVv0f7B+V8nMG6g@mail.gmail.com>

Sorry for the short notice, I thought I already sent the mail, it was
waiting in my draft basket :-(.
BTW it's "Bonjour" in French ;).

Antoine
Le mar. 14 juil. 2015 ? 00:30, John D. Ament <john.d.ament at gmail.com> a
?crit :

> bom dia!
>
> (just got done telling new project manager no Tuesday meetings for this
> one)
>
> John
>
> On Mon, Jul 13, 2015 at 5:12 PM Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
>
>> Hi Guys,
>>
>> I'm on PTO tomorrow (it's Bastille Day) so no meetings.
>>
>> Antoine
>>
> _______________________________________________
>> 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/20150714/094091f1/attachment.html 

From issues at jboss.org  Wed Jul 15 07:49:01 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 15 Jul 2015 07:49:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-540) Clarify
	CDIProvider.isInitialized() javadoc
In-Reply-To: <JIRA.12577395.1436361193000@Atlassian.JIRA>
References: <JIRA.12577395.1436361193000@Atlassian.JIRA>
	<JIRA.12577395.1436361193000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577395.1436361193000.122183.1436960941951@Atlassian.JIRA>


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

Martin Kouba updated CDI-540:
-----------------------------
    Component/s: Java SE Integration


> Clarify CDIProvider.isInitialized() javadoc
> -------------------------------------------
>
>                 Key: CDI-540
>                 URL: https://issues.jboss.org/browse/CDI-540
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java SE Integration
>    Affects Versions: 2.0-EDR1
>            Reporter: Martin Kouba
>
> I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul 15 08:02:01 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 15 Jul 2015 08:02:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-540) Clarify CDI container
 initialization in Java SE
In-Reply-To: <JIRA.12577395.1436361193000@Atlassian.JIRA>
References: <JIRA.12577395.1436361193000@Atlassian.JIRA>
	<JIRA.12577395.1436361193000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577395.1436361193000.122203.1436961721959@Atlassian.JIRA>


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

Martin Kouba updated CDI-540:
-----------------------------
    Summary: Clarify CDI container initialization in Java SE  (was: Clarify CDIProvider.isInitialized() javadoc)


> Clarify CDI container initialization in Java SE
> -----------------------------------------------
>
>                 Key: CDI-540
>                 URL: https://issues.jboss.org/browse/CDI-540
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java SE Integration
>    Affects Versions: 2.0-EDR1
>            Reporter: Martin Kouba
>
> I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul 15 08:06:01 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 15 Jul 2015 08:06:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-540) Clarify CDI container
 initialization in Java SE
In-Reply-To: <JIRA.12577395.1436361193000@Atlassian.JIRA>
References: <JIRA.12577395.1436361193000@Atlassian.JIRA>
	<JIRA.12577395.1436361193000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577395.1436361193000.122215.1436961961970@Atlassian.JIRA>


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

Martin Kouba updated CDI-540:
-----------------------------
    Description: 
{{CDIProvider.isInitialized()}} javadoc should be clarified. I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_.

{{CDI.shutdown()}} currently must throw an {{IllegalStateException}} if the container is already stopped (actually, the javadoc is missing this piece of information). However, there is no way how to find out whether a CDI container is running or not. {{CDIProvider.isInitialized()}} would be usable if multiple running containers were forbidden (which I hope will not be). Also it wouldn't make sense to ask an instance of {{CDIProvider}} whether a concrete {{CDI}} instance is running...

  was:I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_.



> Clarify CDI container initialization in Java SE
> -----------------------------------------------
>
>                 Key: CDI-540
>                 URL: https://issues.jboss.org/browse/CDI-540
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java SE Integration
>    Affects Versions: 2.0-EDR1
>            Reporter: Martin Kouba
>
> {{CDIProvider.isInitialized()}} javadoc should be clarified. I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_.
> {{CDI.shutdown()}} currently must throw an {{IllegalStateException}} if the container is already stopped (actually, the javadoc is missing this piece of information). However, there is no way how to find out whether a CDI container is running or not. {{CDIProvider.isInitialized()}} would be usable if multiple running containers were forbidden (which I hope will not be). Also it wouldn't make sense to ask an instance of {{CDIProvider}} whether a concrete {{CDI}} instance is running...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul 15 08:45:04 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 15 Jul 2015 08:45:04 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-540) Clarify CDI container
 initialization in Java SE
In-Reply-To: <JIRA.12577395.1436361193000@Atlassian.JIRA>
References: <JIRA.12577395.1436361193000@Atlassian.JIRA>
	<JIRA.12577395.1436361193000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577395.1436361193000.122392.1436964304369@Atlassian.JIRA>


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

Tomas Remes commented on CDI-540:
---------------------------------

I fully agree with this. Why developer needs to ask {{CDIProvider}} whether {{CDI}} is initialized? And what does it mean actually? I think {{CDIProvider.isInitialized()}} method would make more sense as method on {{CDI}} and named like {{isRunning}} (since we have shutdown method). 

> Clarify CDI container initialization in Java SE
> -----------------------------------------------
>
>                 Key: CDI-540
>                 URL: https://issues.jboss.org/browse/CDI-540
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java SE Integration
>    Affects Versions: 2.0-EDR1
>            Reporter: Martin Kouba
>
> {{CDIProvider.isInitialized()}} javadoc should be clarified. I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_.
> {{CDI.shutdown()}} currently must throw an {{IllegalStateException}} if the container is already stopped (actually, the javadoc is missing this piece of information). However, there is no way how to find out whether a CDI container is running or not. {{CDIProvider.isInitialized()}} would be usable if multiple running containers were forbidden (which I hope will not be). Also it wouldn't make sense to ask an instance of {{CDIProvider}} whether a concrete {{CDI}} instance is running...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul 15 09:12:03 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 15 Jul 2015 09:12:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs
 sync observers) is not specified
In-Reply-To: <JIRA.12578132.1436965890000@Atlassian.JIRA>
References: <JIRA.12578132.1436965890000@Atlassian.JIRA>
	<JIRA.12578132.1436965890781@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578132.1436965890000.122513.1436965923843@Atlassian.JIRA>

Tomas Remes created CDI-541:
-------------------------------

             Summary: Ordering of async observers (vs sync observers) is not specified
                 Key: CDI-541
                 URL: https://issues.jboss.org/browse/CDI-541
             Project: CDI Specification Issues
          Issue Type: Feature Request
          Components: Events
    Affects Versions: 2.0-EDR1
            Reporter: Tomas Remes


I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? 
For example:
{{event.fireAsync(new Message());}}

{code}
public class First {
  
   void observeMessage(@Observes @Priority(2000) Message message){} 
}
{code}

{code}
public class Second {
  
   void observeMessage(@ObservesAsync @Priority(2100) Message message){} 
}
{code}

{code}
public class Third {
  
   void observeMessage(@Observes @Priority(2200) Message message){} 
}
{code}
What will be the order in this case? First, Second, Third? First, Third, Second?






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul 15 09:53:04 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 15 Jul 2015 09:53:04 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-542) "10.2.2. Firing events
 asynchronously" update/enhancements
In-Reply-To: <JIRA.12578143.1436968352000@Atlassian.JIRA>
References: <JIRA.12578143.1436968352000@Atlassian.JIRA>
	<JIRA.12578143.1436968352367@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578143.1436968352000.122651.1436968384425@Atlassian.JIRA>

Tomas Remes created CDI-542:
-------------------------------

             Summary: "10.2.2. Firing events asynchronously" update/enhancements
                 Key: CDI-542
                 URL: https://issues.jboss.org/browse/CDI-542
             Project: CDI Specification Issues
          Issue Type: Feature Request
    Affects Versions: 2.0-EDR1
            Reporter: Tomas Remes
            Priority: Minor


This chapter (similar as the preceding) defines in general what does it mean to "fire an event" (sync vs async). Let say I am ordinary reader reading the spec from the beginning and I come to this chapter. 
First of all I guess I will struggle little bit with the notion of ??resolved synchronous observers?? (vs ??resolved asynchronous observers??) 
I think the following important information from "10.3. Observer resolution" could be mentioned earlier or some general description/example could be handy:
{quote}
* The event is fired synchronously and the observer is defined with @Observes.

* The event is fired asynchronously and the observer is defined with @Observes or @ObservesAsync.
{quote}

Second there is following sentence which TBH I have had fairly hard times to understand:
{quote}
If synchronous observer have to be notified, fireAsync returns immediately after the last synchronous observer has returned. Otherwise it returns immediately.
{quote}

...and is IMO wrong. There should be "observers have to be" or "observer has to be" and it could be bit more explanatory. 




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul 15 09:54:01 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 15 Jul 2015 09:54:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-542) "10.2.2. Firing events
 asynchronously" update/enhancements
In-Reply-To: <JIRA.12578143.1436968352000@Atlassian.JIRA>
References: <JIRA.12578143.1436968352000@Atlassian.JIRA>
	<JIRA.12578143.1436968352000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578143.1436968352000.122661.1436968441951@Atlassian.JIRA>


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

Tomas Remes commented on CDI-542:
---------------------------------

This is more my personal feeling/opinion...Maybe I am too bad interpreter.:)

> "10.2.2. Firing events asynchronously" update/enhancements
> ----------------------------------------------------------
>
>                 Key: CDI-542
>                 URL: https://issues.jboss.org/browse/CDI-542
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 2.0-EDR1
>            Reporter: Tomas Remes
>            Priority: Minor
>
> This chapter (similar as the preceding) defines in general what does it mean to "fire an event" (sync vs async). Let say I am ordinary reader reading the spec from the beginning and I come to this chapter. 
> First of all I guess I will struggle little bit with the notion of ??resolved synchronous observers?? (vs ??resolved asynchronous observers??) 
> I think the following important information from "10.3. Observer resolution" could be mentioned earlier or some general description/example could be handy:
> {quote}
> * The event is fired synchronously and the observer is defined with @Observes.
> * The event is fired asynchronously and the observer is defined with @Observes or @ObservesAsync.
> {quote}
> Second there is following sentence which TBH I have had fairly hard times to understand:
> {quote}
> If synchronous observer have to be notified, fireAsync returns immediately after the last synchronous observer has returned. Otherwise it returns immediately.
> {quote}
> ...and is IMO wrong. There should be "observers have to be" or "observer has to be" and it could be bit more explanatory. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul 15 11:52:02 2015
From: issues at jboss.org (Mark Paluch (JIRA))
Date: Wed, 15 Jul 2015 11:52:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs
 sync observers) is not specified
In-Reply-To: <JIRA.12578132.1436965890000@Atlassian.JIRA>
References: <JIRA.12578132.1436965890000@Atlassian.JIRA>
	<JIRA.12578132.1436965890000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578132.1436965890000.124296.1436975522347@Atlassian.JIRA>


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

Mark Paluch commented on CDI-541:
---------------------------------

{{@Priority}} is not defined for the async part, it just says
{quote}
If synchronous observer have to be notified, fireAsync returns immediately after the last synchronous observer has returned.
{quote}
So {{@Priority}} is valid (even in the context of {{fireAsync}}) to {{@Observes}}.

> Ordering of async observers (vs sync observers) is not specified
> ----------------------------------------------------------------
>
>                 Key: CDI-541
>                 URL: https://issues.jboss.org/browse/CDI-541
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Tomas Remes
>
> I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? 
> For example:
> {{event.fireAsync(new Message());}}
> {code}
> public class First {
>   
>    void observeMessage(@Observes @Priority(2000) Message message){} 
> }
> {code}
> {code}
> public class Second {
>   
>    void observeMessage(@ObservesAsync @Priority(2100) Message message){} 
> }
> {code}
> {code}
> public class Third {
>   
>    void observeMessage(@Observes @Priority(2200) Message message){} 
> }
> {code}
> What will be the order in this case? First, Second, Third? First, Third, Second?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Jul 16 02:12:02 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 16 Jul 2015 02:12:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs
 sync observers) is not specified
In-Reply-To: <JIRA.12578132.1436965890000@Atlassian.JIRA>
References: <JIRA.12578132.1436965890000@Atlassian.JIRA>
	<JIRA.12578132.1436965890000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578132.1436965890000.125493.1437027122740@Atlassian.JIRA>


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

Martin Kouba commented on CDI-541:
----------------------------------

I think the question is whether to support priority for async observers or not. If we do, all async observers would have to be notified serially, probably in a single thread (this is what we do in Weld right now). This would be handy if a mutable event payload is used. On the other hand, this would also prevent further optimizations (e.g. notify async observers in parallel).

> Ordering of async observers (vs sync observers) is not specified
> ----------------------------------------------------------------
>
>                 Key: CDI-541
>                 URL: https://issues.jboss.org/browse/CDI-541
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Tomas Remes
>
> I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? 
> For example:
> {{event.fireAsync(new Message());}}
> {code}
> public class First {
>   
>    void observeMessage(@Observes @Priority(2000) Message message){} 
> }
> {code}
> {code}
> public class Second {
>   
>    void observeMessage(@ObservesAsync @Priority(2100) Message message){} 
> }
> {code}
> {code}
> public class Third {
>   
>    void observeMessage(@Observes @Priority(2200) Message message){} 
> }
> {code}
> What will be the order in this case? First, Second, Third? First, Third, Second?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Jul 16 02:20:03 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Thu, 16 Jul 2015 02:20:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs
 sync observers) is not specified
In-Reply-To: <JIRA.12578132.1436965890000@Atlassian.JIRA>
References: <JIRA.12578132.1436965890000@Atlassian.JIRA>
	<JIRA.12578132.1436965890000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578132.1436965890000.125499.1437027603079@Atlassian.JIRA>


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

Tomas Remes updated CDI-541:
----------------------------
    Description: 
I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? 
For example:
{{event.fireAsync(new Message());}}

{code}
public class First {
  
   void observeMessage(@Observes @Priority(2000) Message message){} 
}
{code}

{code}
public class Second {
  
   void observeMessage(@ObservesAsync @Priority(2100) Message message){} 
}
{code}

{code}
public class Third {
  
   void observeMessage(@Observes @Priority(2200) Message message){} 
}
{code}

{code}
public class Fourth {
  
   void observeMessage(@ObservesAsync @Priority(2300) Message message){} 
}
{code}
What will be the order in this case? First, Third, Second, Fourth?




  was:
I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? 
For example:
{{event.fireAsync(new Message());}}

{code}
public class First {
  
   void observeMessage(@Observes @Priority(2000) Message message){} 
}
{code}

{code}
public class Second {
  
   void observeMessage(@ObservesAsync @Priority(2100) Message message){} 
}
{code}

{code}
public class Third {
  
   void observeMessage(@Observes @Priority(2200) Message message){} 
}
{code}
What will be the order in this case? First, Second, Third? First, Third, Second?






{quote}
@Priority is not defined for the async part, it just says
{quote}
I guess this is not explicitly stated anywhere. Is it? Ok so sync observers go first anytime so let's focus only on the async observers. I am adding one more @ObservesAsync to the game. 

> Ordering of async observers (vs sync observers) is not specified
> ----------------------------------------------------------------
>
>                 Key: CDI-541
>                 URL: https://issues.jboss.org/browse/CDI-541
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Tomas Remes
>
> I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? 
> For example:
> {{event.fireAsync(new Message());}}
> {code}
> public class First {
>   
>    void observeMessage(@Observes @Priority(2000) Message message){} 
> }
> {code}
> {code}
> public class Second {
>   
>    void observeMessage(@ObservesAsync @Priority(2100) Message message){} 
> }
> {code}
> {code}
> public class Third {
>   
>    void observeMessage(@Observes @Priority(2200) Message message){} 
> }
> {code}
> {code}
> public class Fourth {
>   
>    void observeMessage(@ObservesAsync @Priority(2300) Message message){} 
> }
> {code}
> What will be the order in this case? First, Third, Second, Fourth?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Jul 16 06:01:01 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Thu, 16 Jul 2015 06:01:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-543) Handling exception during async
 event - contradiction?
In-Reply-To: <JIRA.12578254.1437040828000@Atlassian.JIRA>
References: <JIRA.12578254.1437040828000@Atlassian.JIRA>
	<JIRA.12578254.1437040828573@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578254.1437040828000.125976.1437040861946@Atlassian.JIRA>

Tomas Remes created CDI-543:
-------------------------------

             Summary: Handling exception during async event - contradiction?
                 Key: CDI-543
                 URL: https://issues.jboss.org/browse/CDI-543
             Project: CDI Specification Issues
          Issue Type: Bug
          Components: Events
    Affects Versions: 2.0-EDR1
            Reporter: Tomas Remes


In {{10.5. Observer notification}} there is (wrt sync observer method):
{quote}
Otherwise, the exception aborts processing of the event. No other observer methods of that event will be called
{quote}

This looks like contradiction to {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}} where is:

{quote}
If an event is asynchronous, and an exception is thrown by any of its notified observers, the CompletionStage returned by fireAsync will complete exceptionally ..
{quote}
The question is following: Async Event is fired -> some sync observers are notified -> one of them throws exception -> async observers will be notified or not?
I assume they should be notified and therefore {{10.5. Observer notification}} needs an update. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Jul 16 06:03:01 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Thu, 16 Jul 2015 06:03:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-543) Handling exception during async
 event - contradiction?
In-Reply-To: <JIRA.12578254.1437040828000@Atlassian.JIRA>
References: <JIRA.12578254.1437040828000@Atlassian.JIRA>
	<JIRA.12578254.1437040828000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578254.1437040828000.125978.1437040981947@Atlassian.JIRA>


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

Tomas Remes commented on CDI-543:
---------------------------------

There is already available TCK test - org.jboss.cdi.tck.tests.event.observer.async.handlingExceptions.MultipleExceptionsInObserversNotificationTest

> Handling exception during async event - contradiction?
> ------------------------------------------------------
>
>                 Key: CDI-543
>                 URL: https://issues.jboss.org/browse/CDI-543
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Tomas Remes
>
> In {{10.5. Observer notification}} there is (wrt sync observer method):
> {quote}
> Otherwise, the exception aborts processing of the event. No other observer methods of that event will be called
> {quote}
> This looks like contradiction to {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}} where is:
> {quote}
> If an event is asynchronous, and an exception is thrown by any of its notified observers, the CompletionStage returned by fireAsync will complete exceptionally ..
> {quote}
> The question is following: Async Event is fired -> some sync observers are notified -> one of them throws exception -> async observers will be notified or not?
> I assume they should be notified and therefore {{10.5. Observer notification}} needs an update. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Jul 16 06:53:02 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 16 Jul 2015 06:53:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-543) Handling exception during async
 event - contradiction?
In-Reply-To: <JIRA.12578254.1437040828000@Atlassian.JIRA>
References: <JIRA.12578254.1437040828000@Atlassian.JIRA>
	<JIRA.12578254.1437040828000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578254.1437040828000.126113.1437043982468@Atlassian.JIRA>


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

Martin Kouba commented on CDI-543:
----------------------------------

I think it would be more consistent if an exception thrown by any synchronous observer aborts the processing of the event. On the other hand, this may not be the best thing from the user point of view. E.g. an async observer is suddenly not notified after a sync obser which throws an exception is added.

> Handling exception during async event - contradiction?
> ------------------------------------------------------
>
>                 Key: CDI-543
>                 URL: https://issues.jboss.org/browse/CDI-543
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Tomas Remes
>
> In {{10.5. Observer notification}} there is (wrt sync observer method):
> {quote}
> Otherwise, the exception aborts processing of the event. No other observer methods of that event will be called
> {quote}
> This looks like contradiction to {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}} where is:
> {quote}
> If an event is asynchronous, and an exception is thrown by any of its notified observers, the CompletionStage returned by fireAsync will complete exceptionally ..
> {quote}
> The question is following: Async Event is fired -> some sync observers are notified -> one of them throws exception -> async observers will be notified or not?
> I assume they should be notified and therefore {{10.5. Observer notification}} needs an update. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Jul 16 07:49:02 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Thu, 16 Jul 2015 07:49:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-544) 10.2.3. The Event interface -
 provided executor cannot execute observers notification
In-Reply-To: <JIRA.12578268.1437047327000@Atlassian.JIRA>
References: <JIRA.12578268.1437047327000@Atlassian.JIRA>
	<JIRA.12578268.1437047327713@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578268.1437047327000.126366.1437047342842@Atlassian.JIRA>

Tomas Remes created CDI-544:
-------------------------------

             Summary: 10.2.3. The Event interface - provided executor cannot execute observers notification
                 Key: CDI-544
                 URL: https://issues.jboss.org/browse/CDI-544
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Tomas Remes


{quote}
If the provided executor cannot execute observers notification, an IllegalArgumentException is thrown.
{quote}
What does it mean "cannot execute"? I am not really sure. Does it mean the observer throws an exception which should be wrapped in IAE? 
This would likely contradict {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}}.
Maybe this sentence could be omitted. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From antoine at sabot-durand.net  Thu Jul 16 09:25:40 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 16 Jul 2015 15:25:40 +0200
Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
Message-ID: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>

Hi guys,


Bill Shanon, just pointed me to this test in TCK:

https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/ResolveEnterpriseEventObserverTest.java <https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/ResolveEnterpriseEventObserverTest.java>

It tests the following assertion:

"If the bean is a session bean, the observer method must be either a business method of the EJB or a static method of the bean class.?

The EJB containing the observers for the test is:

https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/Spitz.java <https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/Spitz.java>

The EJB contains one business method coming from a local interface, one from a remote and one static method. the 3 are observers methods

The test expects that the remote business observer method should be called.

Here we have an inconsistency IMO. By doing this we are violating rules the CDI spec regarding the fact that remote EJBs are not CDI beans. And we are calling this remote business method passing the event payload by reference and not by value which violates EJB specification regarding remote EJB.

I suggest that we change the assertion to: 

If the bean is a session bean, the observer method must be either a local business method of the EJB or a static method of the bean class.

and the TCK accordingly. Any thought ?

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

From tremes at redhat.com  Thu Jul 16 09:56:06 2015
From: tremes at redhat.com (Tomas Remes)
Date: Thu, 16 Jul 2015 09:56:06 -0400 (EDT)
Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
In-Reply-To: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>
References: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>
Message-ID: <1792296387.37410927.1437054966395.JavaMail.zimbra@redhat.com>


Hi,

I agree. Shouldn't we specify what happens in opposite case? Or maybe better to update following in "10.4.2. Declaring an observer method" as well:

"If a non-static method of a session bean class has a parameter annotated @Observes, and the method is not a business method of the EJB, the container automatically detects the problem and treats it as a definition error."

Tom

----- Original Message -----
From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
To: "cdi-dev" <cdi-dev at lists.jboss.org>
Sent: Thursday, July 16, 2015 3:25:40 PM
Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs

Hi guys, 


Bill Shanon, just pointed me to this test in TCK: 

https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/ResolveEnterpriseEventObserverTest.java 

It tests the following assertion: 

"If the bean is a session bean, the observer method must be either a business method of the EJB or a static method of the bean class.? 

The EJB containing the observers for the test is: 

https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/Spitz.java 

The EJB contains one business method coming from a local interface, one from a remote and one static method. the 3 are observers methods 

The test expects that the remote business observer method should be called. 

Here we have an inconsistency IMO. By doing this we are violating rules the CDI spec regarding the fact that remote EJBs are not CDI beans. And we are calling this remote business method passing the event payload by reference and not by value which violates EJB specification regarding remote EJB. 

I suggest that we change the assertion to: 

If the bean is a session bean, the observer method must be either a local business method of the EJB or a static method of the bean class. 

and the TCK accordingly. Any thought ? 

Antoine 

_______________________________________________
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 rmannibucau at gmail.com  Thu Jul 16 10:04:46 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Thu, 16 Jul 2015 16:04:46 +0200
Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
In-Reply-To: <1792296387.37410927.1437054966395.JavaMail.zimbra@redhat.com>
References: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>
	<1792296387.37410927.1437054966395.JavaMail.zimbra@redhat.com>
Message-ID: <CACLE=7P4D5xVcpPwmOCA6XYNJa7gVJbNYSMvsyWvHbkZqETDGw@mail.gmail.com>

hmm, this always has been an issue for me since CDI shouldnt know about
these methods at all so how could it specify anything? That said not being
able to fix it in EJB spec I tend to agree with Tomas.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-07-16 15:56 GMT+02:00 Tomas Remes <tremes at redhat.com>:

>
> Hi,
>
> I agree. Shouldn't we specify what happens in opposite case? Or maybe
> better to update following in "10.4.2. Declaring an observer method" as
> well:
>
> "If a non-static method of a session bean class has a parameter annotated
> @Observes, and the method is not a business method of the EJB, the
> container automatically detects the problem and treats it as a definition
> error."
>
> Tom
>
> ----- Original Message -----
> From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
> To: "cdi-dev" <cdi-dev at lists.jboss.org>
> Sent: Thursday, July 16, 2015 3:25:40 PM
> Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
>
> Hi guys,
>
>
> Bill Shanon, just pointed me to this test in TCK:
>
>
> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/ResolveEnterpriseEventObserverTest.java
>
> It tests the following assertion:
>
> "If the bean is a session bean, the observer method must be either a
> business method of the EJB or a static method of the bean class.?
>
> The EJB containing the observers for the test is:
>
>
> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/Spitz.java
>
> The EJB contains one business method coming from a local interface, one
> from a remote and one static method. the 3 are observers methods
>
> The test expects that the remote business observer method should be called.
>
> Here we have an inconsistency IMO. By doing this we are violating rules
> the CDI spec regarding the fact that remote EJBs are not CDI beans. And we
> are calling this remote business method passing the event payload by
> reference and not by value which violates EJB specification regarding
> remote EJB.
>
> I suggest that we change the assertion to:
>
> If the bean is a session bean, the observer method must be either a local
> business method of the EJB or a static method of the bean class.
>
> and the TCK accordingly. Any thought ?
>
> Antoine
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150716/6a84e800/attachment.html 

From mkouba at redhat.com  Thu Jul 16 10:24:09 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 16 Jul 2015 16:24:09 +0200
Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
In-Reply-To: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>
References: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>
Message-ID: <55A7BE89.9020903@redhat.com>

Dne 16.7.2015 v 15:25 Antoine Sabot-Durand napsal(a):
> Hi guys,
>
>
> Bill Shanon, just pointed me to this test in TCK:
>
> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/ResolveEnterpriseEventObserverTest.java
>
> It tests the following assertion:
>
> "If the bean is a session bean, the observer method must be either a
> business method of the EJB or a static method of the bean class.?
>
> The EJB containing the observers for the test is:
>
> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/Spitz.java
>
> The EJB contains one business method coming from a local interface, one
> from a remote and one static method. the 3 are observers methods
>
> The test expects that the remote business observer method should be called.
>
> Here we have an inconsistency IMO. By doing this we are violating rules
> the CDI spec regarding the fact that remote EJBs are not CDI beans.

Not exactly, the CDI spec only states that remote interfaces are not 
included in the set of bean types. In this case, the set of bean types 
includes LocalInterface and java.lang.Object. However, the set of 
business methods includes observeLocal() and observeRemote() (see also 
the EJB spec). And so the test follows the current wording of the spec.

> And we are calling this remote business method passing the event payload by
> reference and not by value which violates EJB specification regarding
> remote EJB.
>
> I suggest that we change the assertion to:
>
> If the bean is a session bean, the observer method must be either a
> local business method of the EJB or a static method of the bean class.
>
> and the TCK accordingly. Any thought ?

Yes, we should fix the spec wording first (create issue, exclude test, 
fix tck, etc.).

>
> Antoine
>
>
> _______________________________________________
> 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
Software Engineer
Red Hat, Czech Republic

From antoine at sabot-durand.net  Thu Jul 16 10:49:12 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 16 Jul 2015 14:49:12 +0000
Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
In-Reply-To: <CACLE=7P4D5xVcpPwmOCA6XYNJa7gVJbNYSMvsyWvHbkZqETDGw@mail.gmail.com>
References: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>
	<1792296387.37410927.1437054966395.JavaMail.zimbra@redhat.com>
	<CACLE=7P4D5xVcpPwmOCA6XYNJa7gVJbNYSMvsyWvHbkZqETDGw@mail.gmail.com>
Message-ID: <CABu-YBSrpyFWAszWCAgsAwtLyDJjpyR_anGtt_q09Z7PYYa67w@mail.gmail.com>

Yes Tomas I agree, I think it should be detected automatically by the
container so it's good to update 10.4.2 accordingly. The assertion you
mentioned match this test in the TCK:

https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/broken/observer/notBusinessMethod/EJBObserverMethodNotBusinessMethodTest.java

It's more straight forward to work there IMO.

Romain, I don't understand when you write "That said not being able to fix
it in EJB spec". It's not an EJB spec issue but a CDI issue.

Antoine

Le jeu. 16 juil. 2015 ? 16:05, Romain Manni-Bucau <rmannibucau at gmail.com> a
?crit :

> hmm, this always has been an issue for me since CDI shouldnt know about
> these methods at all so how could it specify anything? That said not being
> able to fix it in EJB spec I tend to agree with Tomas.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-07-16 15:56 GMT+02:00 Tomas Remes <tremes at redhat.com>:
>
>>
>> Hi,
>>
>> I agree. Shouldn't we specify what happens in opposite case? Or maybe
>> better to update following in "10.4.2. Declaring an observer method" as
>> well:
>>
>> "If a non-static method of a session bean class has a parameter annotated
>> @Observes, and the method is not a business method of the EJB, the
>> container automatically detects the problem and treats it as a definition
>> error."
>>
>> Tom
>>
>> ----- Original Message -----
>> From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
>> To: "cdi-dev" <cdi-dev at lists.jboss.org>
>> Sent: Thursday, July 16, 2015 3:25:40 PM
>> Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
>>
>> Hi guys,
>>
>>
>> Bill Shanon, just pointed me to this test in TCK:
>>
>>
>> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/ResolveEnterpriseEventObserverTest.java
>>
>> It tests the following assertion:
>>
>> "If the bean is a session bean, the observer method must be either a
>> business method of the EJB or a static method of the bean class.?
>>
>> The EJB containing the observers for the test is:
>>
>>
>> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/Spitz.java
>>
>> The EJB contains one business method coming from a local interface, one
>> from a remote and one static method. the 3 are observers methods
>>
>> The test expects that the remote business observer method should be
>> called.
>>
>> Here we have an inconsistency IMO. By doing this we are violating rules
>> the CDI spec regarding the fact that remote EJBs are not CDI beans. And we
>> are calling this remote business method passing the event payload by
>> reference and not by value which violates EJB specification regarding
>> remote EJB.
>>
>> I suggest that we change the assertion to:
>>
>> If the bean is a session bean, the observer method must be either a local
>> business method of the EJB or a static method of the bean class.
>>
>> and the TCK accordingly. Any thought ?
>>
>> Antoine
>>
>> _______________________________________________
>> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150716/74bd7f5b/attachment-0001.html 

From issues at jboss.org  Thu Jul 16 13:03:01 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 16 Jul 2015 13:03:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-545) Clarify that observers can't be
 remote business method
In-Reply-To: <JIRA.12578315.1437066145000@Atlassian.JIRA>
References: <JIRA.12578315.1437066145000@Atlassian.JIRA>
	<JIRA.12578315.1437066145305@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578315.1437066145000.127406.1437066181956@Atlassian.JIRA>

Antoine Sabot-Durand created CDI-545:
----------------------------------------

             Summary: Clarify that observers can't be remote business method 
                 Key: CDI-545
                 URL: https://issues.jboss.org/browse/CDI-545
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Java EE integration
    Affects Versions: 1.2.Final
            Reporter: Antoine Sabot-Durand


In section 10.4 of 1.2 spec we have:

{quote}
If the bean is a session bean, the observer method must be either a business method of the EJB or a static method of the bean class.
{quote}

in 10.4.2 we also have:

{quote}
If a non-static method of a session bean class has a parameter annotated {{@Observes}}, and the method is not a business method of the EJB, the container automatically detects the problem and treats it as a definition error.
{quote}

This 2 assertions don't prevent an observer to be a business method of a remote client of an EJB. We should be more precise here and forbid this scenario.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Jul 16 13:16:02 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 16 Jul 2015 13:16:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-544) 10.2.3. The Event interface -
 provided executor cannot execute observers notification
In-Reply-To: <JIRA.12578268.1437047327000@Atlassian.JIRA>
References: <JIRA.12578268.1437047327000@Atlassian.JIRA>
	<JIRA.12578268.1437047327000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578268.1437047327000.127408.1437066962292@Atlassian.JIRA>


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

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

It certainly could be clarified, but the idea here is to have a different exception if something happens inside event dispatcher and not observers (user code). For instance a user may provide a shut down executor that will not be able to run our async observer not because of their content. We have 2 options here:

# Expose the exception coming from the faulty executor, could be not very user friendly
# Wrap it in our own execption with our own error message. Perhaps {{IllegalArgumentException}} is not the best choice

> 10.2.3. The Event interface - provided executor cannot execute observers notification
> -------------------------------------------------------------------------------------
>
>                 Key: CDI-544
>                 URL: https://issues.jboss.org/browse/CDI-544
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>
> {quote}
> If the provided executor cannot execute observers notification, an IllegalArgumentException is thrown.
> {quote}
> What does it mean "cannot execute"? I am not really sure. Does it mean the observer throws an exception which should be wrapped in IAE? 
> This would likely contradict {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}}.
> Maybe this sentence could be omitted. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From rmannibucau at gmail.com  Thu Jul 16 13:22:03 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Thu, 16 Jul 2015 19:22:03 +0200
Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
In-Reply-To: <CABu-YBSrpyFWAszWCAgsAwtLyDJjpyR_anGtt_q09Z7PYYa67w@mail.gmail.com>
References: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>
	<1792296387.37410927.1437054966395.JavaMail.zimbra@redhat.com>
	<CACLE=7P4D5xVcpPwmOCA6XYNJa7gVJbNYSMvsyWvHbkZqETDGw@mail.gmail.com>
	<CABu-YBSrpyFWAszWCAgsAwtLyDJjpyR_anGtt_q09Z7PYYa67w@mail.gmail.com>
Message-ID: <CACLE=7N0OX3+Ho6Xin9kitdbZNkKzSGnLBO7jZwoftCzn-crxg@mail.gmail.com>

For me CDI should only see EJB API and not the impl which is the
responsability of the EJB container *only*.

2015-07-16 16:49 GMT+02:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

> Yes Tomas I agree, I think it should be detected automatically by the
> container so it's good to update 10.4.2 accordingly. The assertion you
> mentioned match this test in the TCK:
>
>
> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/broken/observer/notBusinessMethod/EJBObserverMethodNotBusinessMethodTest.java
>
> It's more straight forward to work there IMO.
>
> Romain, I don't understand when you write "That said not being able to
> fix it in EJB spec". It's not an EJB spec issue but a CDI issue.
>
> Antoine
>
> Le jeu. 16 juil. 2015 ? 16:05, Romain Manni-Bucau <rmannibucau at gmail.com>
> a ?crit :
>
>> hmm, this always has been an issue for me since CDI shouldnt know about
>> these methods at all so how could it specify anything? That said not being
>> able to fix it in EJB spec I tend to agree with Tomas.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>
>> 2015-07-16 15:56 GMT+02:00 Tomas Remes <tremes at redhat.com>:
>>
>>>
>>> Hi,
>>>
>>> I agree. Shouldn't we specify what happens in opposite case? Or maybe
>>> better to update following in "10.4.2. Declaring an observer method" as
>>> well:
>>>
>>> "If a non-static method of a session bean class has a parameter
>>> annotated @Observes, and the method is not a business method of the EJB,
>>> the container automatically detects the problem and treats it as a
>>> definition error."
>>>
>>> Tom
>>>
>>> ----- Original Message -----
>>> From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
>>> To: "cdi-dev" <cdi-dev at lists.jboss.org>
>>> Sent: Thursday, July 16, 2015 3:25:40 PM
>>> Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
>>>
>>> Hi guys,
>>>
>>>
>>> Bill Shanon, just pointed me to this test in TCK:
>>>
>>>
>>> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/ResolveEnterpriseEventObserverTest.java
>>>
>>> It tests the following assertion:
>>>
>>> "If the bean is a session bean, the observer method must be either a
>>> business method of the EJB or a static method of the bean class.?
>>>
>>> The EJB containing the observers for the test is:
>>>
>>>
>>> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/Spitz.java
>>>
>>> The EJB contains one business method coming from a local interface, one
>>> from a remote and one static method. the 3 are observers methods
>>>
>>> The test expects that the remote business observer method should be
>>> called.
>>>
>>> Here we have an inconsistency IMO. By doing this we are violating rules
>>> the CDI spec regarding the fact that remote EJBs are not CDI beans. And we
>>> are calling this remote business method passing the event payload by
>>> reference and not by value which violates EJB specification regarding
>>> remote EJB.
>>>
>>> I suggest that we change the assertion to:
>>>
>>> If the bean is a session bean, the observer method must be either a
>>> local business method of the EJB or a static method of the bean class.
>>>
>>> and the TCK accordingly. Any thought ?
>>>
>>> Antoine
>>>
>>> _______________________________________________
>>> 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.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150716/588ebaa5/attachment.html 

From antoine at sabot-durand.net  Mon Jul 20 03:03:31 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 20 Jul 2015 07:03:31 +0000
Subject: [cdi-dev] Tomorrow's meeting agenda
Message-ID: <CABu-YBQNir0LupY7qw-R7LTtACTrmnFiRuQEZ3W14LTsYqai1w@mail.gmail.com>

Hi all,

I propose the following agenda for tomorrow:

1) Launch AOP workshop:
- AOP support on custom beans
- AOP support on producers
- Self Injection or AOP activated when method called from inside beans
- Decorators without Interface
2) Finishing SE part
- Context control in SE (CDI 530)
- Bean Discovery in SE (CDI 529)
3) CDI-129 (bean visibility) if we have time

Hope to see you online tomorrow

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150720/a247a4c9/attachment.html 

From jharting at redhat.com  Mon Jul 20 09:31:38 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 20 Jul 2015 15:31:38 +0200
Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
In-Reply-To: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>
References: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>
Message-ID: <55ACF83A.9080905@redhat.com>

As Martin explained, it is not the case that "remote EJBs are not CDI 
beans". Therefore, I am wondering why this behavior is a problem? AFAIK 
all the CDI implementations pass this test and therefore there may (at 
least in theory) be applications relying on this behavior.

Jozef

On 16.7.2015 15:25, Antoine Sabot-Durand wrote:
> Hi guys,
>
>
> Bill Shanon, just pointed me to this test in TCK:
>
> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/ResolveEnterpriseEventObserverTest.java
>
> It tests the following assertion:
>
> "If the bean is a session bean, the observer method must be either a
> business method of the EJB or a static method of the bean class.?
>
> The EJB containing the observers for the test is:
>
> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/Spitz.java
>
> The EJB contains one business method coming from a local interface, one
> from a remote and one static method. the 3 are observers methods
>
> The test expects that the remote business observer method should be called.
>
> Here we have an inconsistency IMO. By doing this we are violating rules
> the CDI spec regarding the fact that remote EJBs are not CDI beans. And
> we are calling this remote business method passing the event payload by
> reference and not by value which violates EJB specification regarding
> remote EJB.
>
> I suggest that we change the assertion to:
>
> If the bean is a session bean, the observer method must be either a
> local business method of the EJB or a static method of the bean class.
>
> and the TCK accordingly. Any thought ?
>
> Antoine
>
>
> _______________________________________________
> 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 rmannibucau at gmail.com  Mon Jul 20 09:42:24 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Mon, 20 Jul 2015 06:42:24 -0700
Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
In-Reply-To: <55ACF83A.9080905@redhat.com>
References: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>
	<55ACF83A.9080905@redhat.com>
Message-ID: <CACLE=7M0xoqxds=z-_SECMdeGU1U_BJcVqRYXJ6Q4yh7OqXktg@mail.gmail.com>

This mainly implies failure cases so I guess as much apps rely on it that
apps relying on impl and vendor specific behavior.

That said not sure we need to spend time on it being said EJB are not being
updated much and are slowly replaced by other spec.

Side note: this last point makes me think for future integration CDI should
limit itself to the "contract" with other spec fully ignoring impl in its
own wording. Maybe it is the lesson we need to learn.
 Le 20 juil. 2015 15:31, "Jozef Hartinger" <jharting at redhat.com> a ?crit :

> As Martin explained, it is not the case that "remote EJBs are not CDI
> beans". Therefore, I am wondering why this behavior is a problem? AFAIK
> all the CDI implementations pass this test and therefore there may (at
> least in theory) be applications relying on this behavior.
>
> Jozef
>
> On 16.7.2015 15:25, Antoine Sabot-Durand wrote:
> > Hi guys,
> >
> >
> > Bill Shanon, just pointed me to this test in TCK:
> >
> >
> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/ResolveEnterpriseEventObserverTest.java
> >
> > It tests the following assertion:
> >
> > "If the bean is a session bean, the observer method must be either a
> > business method of the EJB or a static method of the bean class.?
> >
> > The EJB containing the observers for the test is:
> >
> >
> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/Spitz.java
> >
> > The EJB contains one business method coming from a local interface, one
> > from a remote and one static method. the 3 are observers methods
> >
> > The test expects that the remote business observer method should be
> called.
> >
> > Here we have an inconsistency IMO. By doing this we are violating rules
> > the CDI spec regarding the fact that remote EJBs are not CDI beans. And
> > we are calling this remote business method passing the event payload by
> > reference and not by value which violates EJB specification regarding
> > remote EJB.
> >
> > I suggest that we change the assertion to:
> >
> > If the bean is a session bean, the observer method must be either a
> > local business method of the EJB or a static method of the bean class.
> >
> > and the TCK accordingly. Any thought ?
> >
> > Antoine
> >
> >
> > _______________________________________________
> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150720/28fee011/attachment.html 

From antoine at sabot-durand.net  Mon Jul 20 10:24:50 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 20 Jul 2015 14:24:50 +0000
Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
In-Reply-To: <55ACF83A.9080905@redhat.com>
References: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>
	<55ACF83A.9080905@redhat.com>
Message-ID: <CABu-YBTVdQ3L9woOYC3qj-ZqbV8WPdFB=L9uJUxaoRr4gXQcpA@mail.gmail.com>

Le lun. 20 juil. 2015 ? 15:31, Jozef Hartinger <jharting at redhat.com> a
?crit :

> As Martin explained, it is not the case that "remote EJBs are not CDI
> beans".


It's not written in black and white but in section 3.7 resources (
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#resources) ,  remote EJB
are defined as resources and may can't be directly injected.
So if remote EJB are beans EntityManager or Web Services are as well.



> Therefore, I am wondering why this behavior is a problem? AFAIK
> all the CDI implementations pass this test and therefore there may (at
> least in theory) be applications relying on this behavior.
>

As said in my first mail, EJB spec sates (section 3.2.1)

"The arguments and results of the methods of the remote business interface
are passed by value."

I may be wrong but the observer in in the remote EJB is called with
arguments passed by reference. So we are violating EJB specification.

So IMO we should do something about this. Because the original concern of
Bill was about beans injected in remote method observer parameters and how
they were copied.

Any thought?

Antoine



>
> Jozef
>
> On 16.7.2015 15:25, Antoine Sabot-Durand wrote:
> > Hi guys,
> >
> >
> > Bill Shanon, just pointed me to this test in TCK:
> >
> >
> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/ResolveEnterpriseEventObserverTest.java
> >
> > It tests the following assertion:
> >
> > "If the bean is a session bean, the observer method must be either a
> > business method of the EJB or a static method of the bean class.?
> >
> > The EJB containing the observers for the test is:
> >
> >
> https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/Spitz.java
> >
> > The EJB contains one business method coming from a local interface, one
> > from a remote and one static method. the 3 are observers methods
> >
> > The test expects that the remote business observer method should be
> called.
> >
> > Here we have an inconsistency IMO. By doing this we are violating rules
> > the CDI spec regarding the fact that remote EJBs are not CDI beans. And
> > we are calling this remote business method passing the event payload by
> > reference and not by value which violates EJB specification regarding
> > remote EJB.
> >
> > I suggest that we change the assertion to:
> >
> > If the bean is a session bean, the observer method must be either a
> > local business method of the EJB or a static method of the bean class.
> >
> > and the TCK accordingly. Any thought ?
> >
> > Antoine
> >
> >
> > _______________________________________________
> > 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/20150720/e803a453/attachment.html 

From jharting at redhat.com  Mon Jul 20 11:05:54 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 20 Jul 2015 17:05:54 +0200
Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
In-Reply-To: <CABu-YBTVdQ3L9woOYC3qj-ZqbV8WPdFB=L9uJUxaoRr4gXQcpA@mail.gmail.com>
References: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>
	<55ACF83A.9080905@redhat.com>
	<CABu-YBTVdQ3L9woOYC3qj-ZqbV8WPdFB=L9uJUxaoRr4gXQcpA@mail.gmail.com>
Message-ID: <55AD0E52.30402@redhat.com>



On 20.7.2015 16:24, Antoine Sabot-Durand wrote:
>
>
> Le lun. 20 juil. 2015 ? 15:31, Jozef Hartinger <jharting at redhat.com
> <mailto:jharting at redhat.com>> a ?crit :
>
>     As Martin explained, it is not the case that "remote EJBs are not CDI
>     beans".
>
>
> It's not written in black and white but in section 3.7 resources
> (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#resources) ,  remote
> EJB are defined as resources and may can't be directly injected.
> So if remote EJB are beans EntityManager or Web Services are as well.

Section 3.7 talks about injecting *references* to resources. In case of 
remote EJBs and web services this would be clients (stubs) for accessing 
those components. This section does not say anything about the component 
definitions themselves.

>
>     Therefore, I am wondering why this behavior is a problem? AFAIK
>     all the CDI implementations pass this test and therefore there may (at
>     least in theory) be applications relying on this behavior.
>
>
> As said in my first mail, EJB spec sates (section 3.2.1)
>
> "The arguments and results of the methods of the remote business
> interface are passed by value."
>
> I may be wrong but the observer in in the remote EJB is called with
> arguments passed by reference. So we are violating EJB specification.
>
> So IMO we should do something about this. Because the original concern
> of Bill was about beans injected in remote method observer parameters
> and how they were copied.

I see. This is quite weird then.

>
> Any thought?
>
> Antoine
>
>
>     Jozef
>
>     On 16.7.2015 15:25, Antoine Sabot-Durand wrote:
>      > Hi guys,
>      >
>      >
>      > Bill Shanon, just pointed me to this test in TCK:
>      >
>      >
>     https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/ResolveEnterpriseEventObserverTest.java
>      >
>      > It tests the following assertion:
>      >
>      > "If the bean is a session bean, the observer method must be either a
>      > business method of the EJB or a static method of the bean class.?
>      >
>      > The EJB containing the observers for the test is:
>      >
>      >
>     https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/Spitz.java
>      >
>      > The EJB contains one business method coming from a local
>     interface, one
>      > from a remote and one static method. the 3 are observers methods
>      >
>      > The test expects that the remote business observer method should
>     be called.
>      >
>      > Here we have an inconsistency IMO. By doing this we are violating
>     rules
>      > the CDI spec regarding the fact that remote EJBs are not CDI
>     beans. And
>      > we are calling this remote business method passing the event
>     payload by
>      > reference and not by value which violates EJB specification regarding
>      > remote EJB.
>      >
>      > I suggest that we change the assertion to:
>      >
>      > If the bean is a session bean, the observer method must be either a
>      > local business method of the EJB or a static method of the bean
>     class.
>      >
>      > and the TCK accordingly. Any thought ?
>      >
>      > Antoine
>      >
>      >
>      > _______________________________________________
>      > cdi-dev mailing list
>      > cdi-dev at lists.jboss.org <mailto: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 struberg at yahoo.de  Wed Jul 22 01:24:27 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Wed, 22 Jul 2015 07:24:27 +0200
Subject: [cdi-dev] Let's Sept 25th -26th for our F2F meeting
In-Reply-To: <CAOqetn9GX_vYdwskK88kBcMfHhQrH3OfkvmWDL+6p0zmYr5kZg@mail.gmail.com>
References: <4C409AF7-57D7-4B62-A82F-B40EC9C778BC@sabot-durand.net>
	<CAOqetn9GX_vYdwskK88kBcMfHhQrH3OfkvmWDL+6p0zmYr5kZg@mail.gmail.com>
Message-ID: <C1D3C8CE-E045-46C4-98B8-65B0ADD9D810@yahoo.de>

Folks what was the final date now?

Need to manage my dates and check a flight etc.

LieGrue,
strub


> Am 30.06.2015 um 14:55 schrieb John D. Ament <john.d.ament at gmail.com>:
> 
> Hi Antoine,
> 
> Sorry, somethings are coming up at work and I won't be around either of those weekends now :-(
> If 18th is more convenient for people please use that.
> 
> John
> 
> On Thu, Jun 25, 2015 at 10:17 AM Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
> Hi all,
> 
> So the vote closed on modally. We should have talk about the final date in the last meeting, but there was too much on our plate ;).
> 
> We have a tie between 18th and 25th, but as John can make it for the 25th and he?s probably the farthest one from Paris to come I propose to keep this date.
> 
> Regards,
> 
> Antoine
> 
> 
> _______________________________________________
> 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.



From issues at jboss.org  Wed Jul 22 02:13:06 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 22 Jul 2015 02:13:06 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-546) Constant for default observer
	priority
In-Reply-To: <JIRA.12578846.1437545572000@Atlassian.JIRA>
References: <JIRA.12578846.1437545572000@Atlassian.JIRA>
	<JIRA.12578846.1437545572289@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578846.1437545572000.139334.1437545586140@Atlassian.JIRA>

Jozef Hartinger created CDI-546:
-----------------------------------

             Summary: Constant for default observer priority
                 Key: CDI-546
                 URL: https://issues.jboss.org/browse/CDI-546
             Project: CDI Specification Issues
          Issue Type: Feature Request
            Reporter: Jozef Hartinger
            Priority: Minor


Currently we use:

{code:JAVA}
    @Override
    public default int getPriority() {
        return javax.interceptor.Interceptor.Priority.APPLICATION + 500;
    };

{code}

It would be nice to have the value stored as a constant e.g.:

{code:JAVA}
int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500;
{code}

so that other code can reference it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul 22 02:28:02 2015
From: issues at jboss.org (George Gastaldi (JIRA))
Date: Wed, 22 Jul 2015 02:28:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-546) Constant for default observer
	priority
In-Reply-To: <JIRA.12578846.1437545572000@Atlassian.JIRA>
References: <JIRA.12578846.1437545572000@Atlassian.JIRA>
	<JIRA.12578846.1437545572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578846.1437545572000.139384.1437546482306@Atlassian.JIRA>


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

George Gastaldi commented on CDI-546:
-------------------------------------

Although this is specified as a default for CDI 2.0, is it safe to assume that this value will be default for other specs that use the Interceptor annotation (eg. EJB)? Maybe we should involve the EJB spec team in this?

> Constant for default observer priority
> --------------------------------------
>
>                 Key: CDI-546
>                 URL: https://issues.jboss.org/browse/CDI-546
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Jozef Hartinger
>            Priority: Minor
>
> Currently we use:
> {code:JAVA}
>     @Override
>     public default int getPriority() {
>         return javax.interceptor.Interceptor.Priority.APPLICATION + 500;
>     };
> {code}
> It would be nice to have the value stored as a constant e.g.:
> {code:JAVA}
> int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500;
> {code}
> so that other code can reference it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul 22 02:29:08 2015
From: issues at jboss.org (George Gastaldi (JIRA))
Date: Wed, 22 Jul 2015 02:29:08 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-546) Constant for default observer
	priority
In-Reply-To: <JIRA.12578846.1437545572000@Atlassian.JIRA>
References: <JIRA.12578846.1437545572000@Atlassian.JIRA>
	<JIRA.12578846.1437545572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578846.1437545572000.139400.1437546548129@Atlassian.JIRA>


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

George Gastaldi commented on CDI-546:
-------------------------------------

Unless I misunderstood and you mean to create this constant in one of the CDI classes, then disregard my last comment

> Constant for default observer priority
> --------------------------------------
>
>                 Key: CDI-546
>                 URL: https://issues.jboss.org/browse/CDI-546
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Jozef Hartinger
>            Priority: Minor
>
> Currently we use:
> {code:JAVA}
>     @Override
>     public default int getPriority() {
>         return javax.interceptor.Interceptor.Priority.APPLICATION + 500;
>     };
> {code}
> It would be nice to have the value stored as a constant e.g.:
> {code:JAVA}
> int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500;
> {code}
> so that other code can reference it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul 22 02:30:03 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 22 Jul 2015 02:30:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-546) Constant for default observer
	priority
In-Reply-To: <JIRA.12578846.1437545572000@Atlassian.JIRA>
References: <JIRA.12578846.1437545572000@Atlassian.JIRA>
	<JIRA.12578846.1437545572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578846.1437545572000.139418.1437546603327@Atlassian.JIRA>


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

Jozef Hartinger commented on CDI-546:
-------------------------------------

This is a default value for observer methods. Interceptors do not have a default value.

> Constant for default observer priority
> --------------------------------------
>
>                 Key: CDI-546
>                 URL: https://issues.jboss.org/browse/CDI-546
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Jozef Hartinger
>            Priority: Minor
>
> Currently we use:
> {code:JAVA}
>     @Override
>     public default int getPriority() {
>         return javax.interceptor.Interceptor.Priority.APPLICATION + 500;
>     };
> {code}
> It would be nice to have the value stored as a constant e.g.:
> {code:JAVA}
> int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500;
> {code}
> so that other code can reference it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul 22 02:30:03 2015
From: issues at jboss.org (George Gastaldi (JIRA))
Date: Wed, 22 Jul 2015 02:30:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-546) Constant for default observer
	priority
In-Reply-To: <JIRA.12578846.1437545572000@Atlassian.JIRA>
References: <JIRA.12578846.1437545572000@Atlassian.JIRA>
	<JIRA.12578846.1437545572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578846.1437545572000.139420.1437546603449@Atlassian.JIRA>


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

George Gastaldi commented on CDI-546:
-------------------------------------

I think we do have a {{Prioritized}} interface for this, no? +1 to include it on that

> Constant for default observer priority
> --------------------------------------
>
>                 Key: CDI-546
>                 URL: https://issues.jboss.org/browse/CDI-546
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Jozef Hartinger
>            Priority: Minor
>
> Currently we use:
> {code:JAVA}
>     @Override
>     public default int getPriority() {
>         return javax.interceptor.Interceptor.Priority.APPLICATION + 500;
>     };
> {code}
> It would be nice to have the value stored as a constant e.g.:
> {code:JAVA}
> int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500;
> {code}
> so that other code can reference it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul 22 09:55:03 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 22 Jul 2015 09:55:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer
	methods
In-Reply-To: <JIRA.12578938.1437573301000@Atlassian.JIRA>
References: <JIRA.12578938.1437573301000@Atlassian.JIRA>
	<JIRA.12578938.1437573301688@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578938.1437573301000.140831.1437573303714@Atlassian.JIRA>

Jozef Hartinger created CDI-547:
-----------------------------------

             Summary: Resolving sync/async observer methods
                 Key: CDI-547
                 URL: https://issues.jboss.org/browse/CDI-547
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Jozef Hartinger


There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] method for resolving observer methods.

With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Jul 22 10:02:02 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 22 Jul 2015 10:02:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-548) FireAsyncException conflicting
 with CompletionStage definition
In-Reply-To: <JIRA.12578943.1437573706000@Atlassian.JIRA>
References: <JIRA.12578943.1437573706000@Atlassian.JIRA>
	<JIRA.12578943.1437573706842@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578943.1437573706000.140852.1437573722949@Atlassian.JIRA>

Jozef Hartinger created CDI-548:
-----------------------------------

             Summary: FireAsyncException conflicting with CompletionStage definition
                 Key: CDI-548
                 URL: https://issues.jboss.org/browse/CDI-548
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Events
    Affects Versions: 2.0-EDR1
            Reporter: Jozef Hartinger


CompletionStage documentation says:

{quote}
if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause.
{quote}

On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From EMIJIANG at uk.ibm.com  Wed Jul 22 12:38:48 2015
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Wed, 22 Jul 2015 17:38:48 +0100
Subject: [cdi-dev] Inconsistency in the spec regarding remote EJBs
In-Reply-To: <55AD0E52.30402@redhat.com>
References: <11C22648-DAAD-4CF7-A71D-FB8E7CD751B0@sabot-durand.net>	<55ACF83A.9080905@redhat.com>
	<CABu-YBTVdQ3L9woOYC3qj-ZqbV8WPdFB=L9uJUxaoRr4gXQcpA@mail.gmail.com>
	<55AD0E52.30402@redhat.com>
Message-ID: <OF727B0941.E29320A5-ON80257E8A.005A965B-80257E8A.005B7216@uk.ibm.com>

>
>     Therefore, I am wondering why this behavior is a problem? AFAIK
>     all the CDI implementations pass this test and therefore there may 
(at
>     least in theory) be applications relying on this behavior.
>

I agree that we should not directly change the behaviour as we will break 
customers relying on this behaviour.

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server Liberty Profile development 
 
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone:  +44 (0)1962 816278  Internal: 246278

Email: emijiang at uk.ibm.com 
Lotus Notes: Emily Jiang/UK/IBM at IBMGB




From:   Jozef Hartinger <jharting at redhat.com>
To:     Antoine Sabot-Durand <antoine at sabot-durand.net>, cdi-dev 
<cdi-dev at lists.jboss.org>, 
Date:   20/07/2015 16:07
Subject:        Re: [cdi-dev] Inconsistency in the spec regarding remote 
EJBs
Sent by:        cdi-dev-bounces at lists.jboss.org





On 20.7.2015 16:24, Antoine Sabot-Durand wrote:
>
>
> Le lun. 20 juil. 2015 ? 15:31, Jozef Hartinger <jharting at redhat.com
> <mailto:jharting at redhat.com>> a ?crit :
>
>     As Martin explained, it is not the case that "remote EJBs are not 
CDI
>     beans".
>
>
> It's not written in black and white but in section 3.7 resources
> (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#resources) ,  remote
> EJB are defined as resources and may can't be directly injected.
> So if remote EJB are beans EntityManager or Web Services are as well.

Section 3.7 talks about injecting *references* to resources. In case of 
remote EJBs and web services this would be clients (stubs) for accessing 
those components. This section does not say anything about the component 
definitions themselves.

>
>     Therefore, I am wondering why this behavior is a problem? AFAIK
>     all the CDI implementations pass this test and therefore there may 
(at
>     least in theory) be applications relying on this behavior.
>
>
> As said in my first mail, EJB spec sates (section 3.2.1)
>
> "The arguments and results of the methods of the remote business
> interface are passed by value."
>
> I may be wrong but the observer in in the remote EJB is called with
> arguments passed by reference. So we are violating EJB specification.
>
> So IMO we should do something about this. Because the original concern
> of Bill was about beans injected in remote method observer parameters
> and how they were copied.

I see. This is quite weird then.

>
> Any thought?
>
> Antoine
>
>
>     Jozef
>
>     On 16.7.2015 15:25, Antoine Sabot-Durand wrote:
>      > Hi guys,
>      >
>      >
>      > Bill Shanon, just pointed me to this test in TCK:
>      >
>      >
>     
https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/ResolveEnterpriseEventObserverTest.java

>      >
>      > It tests the following assertion:
>      >
>      > "If the bean is a session bean, the observer method must be 
either a
>      > business method of the EJB or a static method of the bean class.?
>      >
>      > The EJB containing the observers for the test is:
>      >
>      >
>     
https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/resolve/enterprise/Spitz.java

>      >
>      > The EJB contains one business method coming from a local
>     interface, one
>      > from a remote and one static method. the 3 are observers methods
>      >
>      > The test expects that the remote business observer method should
>     be called.
>      >
>      > Here we have an inconsistency IMO. By doing this we are violating
>     rules
>      > the CDI spec regarding the fact that remote EJBs are not CDI
>     beans. And
>      > we are calling this remote business method passing the event
>     payload by
>      > reference and not by value which violates EJB specification 
regarding
>      > remote EJB.
>      >
>      > I suggest that we change the assertion to:
>      >
>      > If the bean is a session bean, the observer method must be either 
a
>      > local business method of the EJB or a static method of the bean
>     class.
>      >
>      > and the TCK accordingly. Any thought ?
>      >
>      > Antoine
>      >
>      >
>      > _______________________________________________
>      > cdi-dev mailing list
>      > cdi-dev at lists.jboss.org <mailto: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.

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

From antoine at sabot-durand.net  Wed Jul 22 14:47:43 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 22 Jul 2015 18:47:43 +0000
Subject: [cdi-dev] Let's Sept 25th -26th for our F2F meeting
In-Reply-To: <C1D3C8CE-E045-46C4-98B8-65B0ADD9D810@yahoo.de>
References: <4C409AF7-57D7-4B62-A82F-B40EC9C778BC@sabot-durand.net>
	<CAOqetn9GX_vYdwskK88kBcMfHhQrH3OfkvmWDL+6p0zmYr5kZg@mail.gmail.com>
	<C1D3C8CE-E045-46C4-98B8-65B0ADD9D810@yahoo.de>
Message-ID: <CABu-YBS7G309HWYsH+XLkdJrKeNRt1jzymTZm1_9-E-rvmLS7w@mail.gmail.com>

For me it's set on the September 25th - 26th. I'll send you a mail about
the organisation in the coming days.

Antoine

Le mer. 22 juil. 2015 ? 07:24, Mark Struberg <struberg at yahoo.de> a ?crit :

> Folks what was the final date now?
>
> Need to manage my dates and check a flight etc.
>
> LieGrue,
> strub
>
>
> > Am 30.06.2015 um 14:55 schrieb John D. Ament <john.d.ament at gmail.com>:
> >
> > Hi Antoine,
> >
> > Sorry, somethings are coming up at work and I won't be around either of
> those weekends now :-(
> > If 18th is more convenient for people please use that.
> >
> > John
> >
> > On Thu, Jun 25, 2015 at 10:17 AM Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
> > Hi all,
> >
> > So the vote closed on modally. We should have talk about the final date
> in the last meeting, but there was too much on our plate ;).
> >
> > We have a tie between 18th and 25th, but as John can make it for the
> 25th and he?s probably the farthest one from Paris to come I propose to
> keep this date.
> >
> > Regards,
> >
> > Antoine
> >
> >
> > _______________________________________________
> > 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150722/044e3115/attachment.html 

From issues at jboss.org  Thu Jul 23 01:41:01 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Thu, 23 Jul 2015 01:41:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-549) Unnecessary statement in "8.1.2.
 Decorator delegate injection points" ?
In-Reply-To: <JIRA.12579015.1437630045000@Atlassian.JIRA>
References: <JIRA.12579015.1437630045000@Atlassian.JIRA>
	<JIRA.12579015.1437630045035@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579015.1437630045000.142916.1437630061949@Atlassian.JIRA>

Tomas Remes created CDI-549:
-------------------------------

             Summary: Unnecessary statement in "8.1.2. Decorator delegate injection points" ?
                 Key: CDI-549
                 URL: https://issues.jboss.org/browse/CDI-549
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Decorators
    Affects Versions: 1.2.Final
            Reporter: Tomas Remes
            Priority: Minor


Decorators cannot declare observers, producers and disposers according to:
{quote}
Interceptors and decorators may not declare producer methods. If an interceptor or decorator has a method annotated @Produces , the container automatically detects the problem and treats it as a definition error.
{quote}
and
{quote}
Interceptors and decorators may not declare observer methods. If an interceptor or decorator has a method with a parameter annotated @Observes , the container automatically detects the problem
and treats it as a definition error.
{quote}

The question is whether following restriction (basically second sentence) is unnecessary because all conditions (in which this could happen) are already excluded in the above restrictions. 
{quote}
The delegate injection point must be an injected field, initializer method parameter or bean constructor method parameter. If an injection point that is not an injected field, initializer method parameter or bean constructor method parameter is annotated @Delegate , the container
automatically detects the problem and treats it as a definition error.
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Jul 23 03:40:03 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 23 Jul 2015 03:40:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-550) Misleading
 AfterBeanDiscovery.addBean() description WRT interceptors and decorators
In-Reply-To: <JIRA.12579021.1437637150000@Atlassian.JIRA>
References: <JIRA.12579021.1437637150000@Atlassian.JIRA>
	<JIRA.12579021.1437637150898@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579021.1437637150000.143281.1437637203071@Atlassian.JIRA>

Martin Kouba created CDI-550:
--------------------------------

             Summary: Misleading AfterBeanDiscovery.addBean() description WRT interceptors and decorators
                 Key: CDI-550
                 URL: https://issues.jboss.org/browse/CDI-550
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Portable Extensions
    Affects Versions: 2.0-EDR1
            Reporter: Martin Kouba
            Priority: Minor


11.5.3. AfterBeanDiscovery event:
{quote}
* {{addBean()}} fires an event of type ProcessBean containing the given Bean and then registers the Bean with the container, thereby making it available for injection into other beans. The given Bean may implement Interceptor or Decorator.
{quote}
The wording is a bit misleading because interceptors and decorats are NOT available for injection.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 24 04:11:06 2015
From: issues at jboss.org (Chris Rankin (JIRA))
Date: Fri, 24 Jul 2015 04:11:06 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-551) Easier access to InjectionPoint
	qualifiers.
In-Reply-To: <JIRA.12579268.1437725435000@Atlassian.JIRA>
References: <JIRA.12579268.1437725435000@Atlassian.JIRA>
	<JIRA.12579268.1437725435209@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579268.1437725435000.147389.1437725466069@Atlassian.JIRA>

Chris Rankin created CDI-551:
--------------------------------

             Summary: Easier access to InjectionPoint qualifiers.
                 Key: CDI-551
                 URL: https://issues.jboss.org/browse/CDI-551
             Project: CDI Specification Issues
          Issue Type: Feature Request
          Components: Beans
    Affects Versions: 1.2.Final
            Reporter: Chris Rankin


I would like to extend {{javax.enterprise.inject.spi.InjectionPoint}} for easier analysis of both static and dynamic qualifiers.

I have previously used {{InjectionPoint.getAnnotated()}}, but have now realised that is not enough because it cannot include {{AnnotationLiteral}} qualifiers added via {{Instance.select(...)}}. The only reliable way to analyse _all_ of the qualifiers is currently via {{InjectionPoint.getQualifiers()}}, which unfortunately returns {{Set<Annotated>}}.

A {{Set<Annotated>>}} is not immediately useful to me; about the only thing that I can do with it is iterate over it every time. So I must convert it into something more like this first:

{code:language=java}
@SuppressWarnings("unchecked")
public class QualifierMap extends HashMap<Class<? extends Annotation>, Annotation> {
    private static final long serialVersionUID = 1L;

    public QualifierMap(Iterable<? extends Annotation> qualifiers) {
        for (Annotation qualifier : qualifiers) {
            put(qualifier.annotationType(), qualifier);
        }
    }

    public <T extends Annotation> T get(Class<T> key) {
        return (T) super.get(key);
    }

}
{code}

However, it would be much _more_ convenient if {{InjectionPoint}} could export this functionality automatically instead:

{code:language=java}
public interface InjectionPoint {

    ...

    boolean isQualifierPresent(Class<? extends Annotation> annotationType);  
 
    <T extends Annotation> T getQualifier(Class<T> annotationType);

    ....

}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 24 04:13:01 2015
From: issues at jboss.org (Chris Rankin (JIRA))
Date: Fri, 24 Jul 2015 04:13:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-551) Easier access to InjectionPoint
	qualifiers.
In-Reply-To: <JIRA.12579268.1437725435000@Atlassian.JIRA>
References: <JIRA.12579268.1437725435000@Atlassian.JIRA>
	<JIRA.12579268.1437725435000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579268.1437725435000.147391.1437725581951@Atlassian.JIRA>


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

Chris Rankin updated CDI-551:
-----------------------------
    Description: 
I would like to extend {{javax.enterprise.inject.spi.InjectionPoint}} for easier analysis of both static and dynamic qualifiers.

I have previously used {{InjectionPoint.getAnnotated()}}, but have now realised that this is not enough because it cannot include {{AnnotationLiteral}} qualifiers added via {{Instance.select(...)}}. The only reliable way to analyse _all_ of the qualifiers is currently via {{InjectionPoint.getQualifiers()}}, which unfortunately returns {{Set<Annotated>}}.

A {{Set<Annotated>>}} is not immediately useful to me; about the only thing that I can do with it is iterate over it every time. So I must convert it into something more like this first:

{code:language=java}
@SuppressWarnings("unchecked")
public class QualifierMap extends HashMap<Class<? extends Annotation>, Annotation> {
    private static final long serialVersionUID = 1L;

    public QualifierMap(Iterable<? extends Annotation> qualifiers) {
        for (Annotation qualifier : qualifiers) {
            put(qualifier.annotationType(), qualifier);
        }
    }

    public <T extends Annotation> T get(Class<T> key) {
        return (T) super.get(key);
    }

}
{code}

However, it would be much _more_ convenient if {{InjectionPoint}} could export this functionality automatically instead:

{code:language=java}
public interface InjectionPoint {

    ...

    boolean isQualifierPresent(Class<? extends Annotation> annotationType);  
 
    <T extends Annotation> T getQualifier(Class<T> annotationType);

    ....

}
{code}

  was:
I would like to extend {{javax.enterprise.inject.spi.InjectionPoint}} for easier analysis of both static and dynamic qualifiers.

I have previously used {{InjectionPoint.getAnnotated()}}, but have now realised that is not enough because it cannot include {{AnnotationLiteral}} qualifiers added via {{Instance.select(...)}}. The only reliable way to analyse _all_ of the qualifiers is currently via {{InjectionPoint.getQualifiers()}}, which unfortunately returns {{Set<Annotated>}}.

A {{Set<Annotated>>}} is not immediately useful to me; about the only thing that I can do with it is iterate over it every time. So I must convert it into something more like this first:

{code:language=java}
@SuppressWarnings("unchecked")
public class QualifierMap extends HashMap<Class<? extends Annotation>, Annotation> {
    private static final long serialVersionUID = 1L;

    public QualifierMap(Iterable<? extends Annotation> qualifiers) {
        for (Annotation qualifier : qualifiers) {
            put(qualifier.annotationType(), qualifier);
        }
    }

    public <T extends Annotation> T get(Class<T> key) {
        return (T) super.get(key);
    }

}
{code}

However, it would be much _more_ convenient if {{InjectionPoint}} could export this functionality automatically instead:

{code:language=java}
public interface InjectionPoint {

    ...

    boolean isQualifierPresent(Class<? extends Annotation> annotationType);  
 
    <T extends Annotation> T getQualifier(Class<T> annotationType);

    ....

}
{code}



> Easier access to InjectionPoint qualifiers.
> -------------------------------------------
>
>                 Key: CDI-551
>                 URL: https://issues.jboss.org/browse/CDI-551
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Chris Rankin
>
> I would like to extend {{javax.enterprise.inject.spi.InjectionPoint}} for easier analysis of both static and dynamic qualifiers.
> I have previously used {{InjectionPoint.getAnnotated()}}, but have now realised that this is not enough because it cannot include {{AnnotationLiteral}} qualifiers added via {{Instance.select(...)}}. The only reliable way to analyse _all_ of the qualifiers is currently via {{InjectionPoint.getQualifiers()}}, which unfortunately returns {{Set<Annotated>}}.
> A {{Set<Annotated>>}} is not immediately useful to me; about the only thing that I can do with it is iterate over it every time. So I must convert it into something more like this first:
> {code:language=java}
> @SuppressWarnings("unchecked")
> public class QualifierMap extends HashMap<Class<? extends Annotation>, Annotation> {
>     private static final long serialVersionUID = 1L;
>     public QualifierMap(Iterable<? extends Annotation> qualifiers) {
>         for (Annotation qualifier : qualifiers) {
>             put(qualifier.annotationType(), qualifier);
>         }
>     }
>     public <T extends Annotation> T get(Class<T> key) {
>         return (T) super.get(key);
>     }
> }
> {code}
> However, it would be much _more_ convenient if {{InjectionPoint}} could export this functionality automatically instead:
> {code:language=java}
> public interface InjectionPoint {
>     ...
>     boolean isQualifierPresent(Class<? extends Annotation> annotationType);  
>  
>     <T extends Annotation> T getQualifier(Class<T> annotationType);
>     ....
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 24 10:18:01 2015
From: issues at jboss.org (Rogerio Liesenfeld (JIRA))
Date: Fri, 24 Jul 2015 10:18:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
 decorators and interceptors on "new-ed" objects
In-Reply-To: <JIRA.12579311.1437747419000@Atlassian.JIRA>
References: <JIRA.12579311.1437747419000@Atlassian.JIRA>
	<JIRA.12579311.1437747419868@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579311.1437747419000.148710.1437747481951@Atlassian.JIRA>

Rogerio Liesenfeld created CDI-552:
--------------------------------------

             Summary: Add support for injection, decorators and interceptors on "new-ed" objects
                 Key: CDI-552
                 URL: https://issues.jboss.org/browse/CDI-552
             Project: CDI Specification Issues
          Issue Type: Epic
          Components: Beans, Decorators, Interceptors, Resolution
    Affects Versions: 2.0-EDR1
            Reporter: Rogerio Liesenfeld


The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.

With this I mean:
1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a <a href="http://martinfowler.com/eaaCatalog/transactionScript.html">Transaction Script</a>).
2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them `final` (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the <a href="http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683">book</a>).
3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.

Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:

MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);

String result1 = businessOp.getResultXyz();
List<result> moreResultData = businessOp.getFinalData();

... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).

Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).

For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.

Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 24 10:20:03 2015
From: issues at jboss.org (Rogerio Liesenfeld (JIRA))
Date: Fri, 24 Jul 2015 10:20:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
 decorators and interceptors on "new-ed" objects
In-Reply-To: <JIRA.12579311.1437747419000@Atlassian.JIRA>
References: <JIRA.12579311.1437747419000@Atlassian.JIRA>
	<JIRA.12579311.1437747419000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579311.1437747419000.148711.1437747603179@Atlassian.JIRA>


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

Rogerio Liesenfeld updated CDI-552:
-----------------------------------
    Description: 
The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.

With this I mean:
1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script](http://martinfowler.com/eaaCatalog/transactionScript.html).
2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them `final` (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the <a href="http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683">book</a>).
3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.

Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:

MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);

String result1 = businessOp.getResultXyz();
List<result> moreResultData = businessOp.getFinalData();

... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).

Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).

For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.

Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html

  was:
The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.

With this I mean:
1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a <a href="http://martinfowler.com/eaaCatalog/transactionScript.html">Transaction Script</a>).
2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them `final` (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the <a href="http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683">book</a>).
3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.

Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:

MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);

String result1 = businessOp.getResultXyz();
List<result> moreResultData = businessOp.getFinalData();

... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).

Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).

For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.

Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



> Add support for injection, decorators and interceptors on "new-ed" objects
> --------------------------------------------------------------------------
>
>                 Key: CDI-552
>                 URL: https://issues.jboss.org/browse/CDI-552
>             Project: CDI Specification Issues
>          Issue Type: Epic
>          Components: Beans, Decorators, Interceptors, Resolution
>    Affects Versions: 2.0-EDR1
>            Reporter: Rogerio Liesenfeld
>
> The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.
> With this I mean:
> 1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script](http://martinfowler.com/eaaCatalog/transactionScript.html).
> 2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them `final` (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the <a href="http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683">book</a>).
> 3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.
> Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = businessOp.getFinalData();
> ... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).
> Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).
> For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.
> Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 24 10:21:02 2015
From: issues at jboss.org (Rogerio Liesenfeld (JIRA))
Date: Fri, 24 Jul 2015 10:21:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
 decorators and interceptors on "new-ed" objects
In-Reply-To: <JIRA.12579311.1437747419000@Atlassian.JIRA>
References: <JIRA.12579311.1437747419000@Atlassian.JIRA>
	<JIRA.12579311.1437747419000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579311.1437747419000.148716.1437747662535@Atlassian.JIRA>


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

Rogerio Liesenfeld updated CDI-552:
-----------------------------------
    Description: 
The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.

With this I mean:
1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them `final` (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the <a href="http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683">book</a>).
3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.

Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:

MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);

String result1 = businessOp.getResultXyz();
List<result> moreResultData = businessOp.getFinalData();

... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).

Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).

For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.

Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html

  was:
The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.

With this I mean:
1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script](http://martinfowler.com/eaaCatalog/transactionScript.html).
2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them `final` (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the <a href="http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683">book</a>).
3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.

Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:

MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);

String result1 = businessOp.getResultXyz();
List<result> moreResultData = businessOp.getFinalData();

... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).

Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).

For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.

Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



> Add support for injection, decorators and interceptors on "new-ed" objects
> --------------------------------------------------------------------------
>
>                 Key: CDI-552
>                 URL: https://issues.jboss.org/browse/CDI-552
>             Project: CDI Specification Issues
>          Issue Type: Epic
>          Components: Beans, Decorators, Interceptors, Resolution
>    Affects Versions: 2.0-EDR1
>            Reporter: Rogerio Liesenfeld
>
> The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.
> With this I mean:
> 1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
> 2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them `final` (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the <a href="http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683">book</a>).
> 3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.
> Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = businessOp.getFinalData();
> ... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).
> Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).
> For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.
> Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 24 10:24:02 2015
From: issues at jboss.org (Rogerio Liesenfeld (JIRA))
Date: Fri, 24 Jul 2015 10:24:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
 decorators and interceptors on "new-ed" objects
In-Reply-To: <JIRA.12579311.1437747419000@Atlassian.JIRA>
References: <JIRA.12579311.1437747419000@Atlassian.JIRA>
	<JIRA.12579311.1437747419000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579311.1437747419000.148724.1437747842907@Atlassian.JIRA>


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

Rogerio Liesenfeld updated CDI-552:
-----------------------------------
    Description: 
The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.

With this I mean:
1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]).
3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.

Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:

MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);

String result1 = businessOp.getResultXyz();
List<result> moreResultData = businessOp.getFinalData();

... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).

Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).

For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.

Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html

  was:
The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.

With this I mean:
1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them `final` (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the <a href="http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683">book</a>).
3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.

Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:

MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);

String result1 = businessOp.getResultXyz();
List<result> moreResultData = businessOp.getFinalData();

... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).

Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).

For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.

Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



> Add support for injection, decorators and interceptors on "new-ed" objects
> --------------------------------------------------------------------------
>
>                 Key: CDI-552
>                 URL: https://issues.jboss.org/browse/CDI-552
>             Project: CDI Specification Issues
>          Issue Type: Epic
>          Components: Beans, Decorators, Interceptors, Resolution
>    Affects Versions: 2.0-EDR1
>            Reporter: Rogerio Liesenfeld
>
> The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.
> With this I mean:
> 1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
> 2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]).
> 3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.
> Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = businessOp.getFinalData();
> ... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).
> Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).
> For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.
> Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 24 10:25:01 2015
From: issues at jboss.org (Rogerio Liesenfeld (JIRA))
Date: Fri, 24 Jul 2015 10:25:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
 decorators and interceptors on "new-ed" objects
In-Reply-To: <JIRA.12579311.1437747419000@Atlassian.JIRA>
References: <JIRA.12579311.1437747419000@Atlassian.JIRA>
	<JIRA.12579311.1437747419000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579311.1437747419000.148727.1437747901963@Atlassian.JIRA>


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

Rogerio Liesenfeld updated CDI-552:
-----------------------------------
    Description: 
The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.

With this I mean:
1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]).
3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.

Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:

{code}
MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);

String result1 = businessOp.getResultXyz();
List<result> moreResultData = businessOp.getFinalData();
{code}

... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).

Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).

For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.

Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html

  was:
The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.

With this I mean:
1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]).
3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.

Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:

MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);

String result1 = businessOp.getResultXyz();
List<result> moreResultData = businessOp.getFinalData();

... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).

Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).

For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.

Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



> Add support for injection, decorators and interceptors on "new-ed" objects
> --------------------------------------------------------------------------
>
>                 Key: CDI-552
>                 URL: https://issues.jboss.org/browse/CDI-552
>             Project: CDI Specification Issues
>          Issue Type: Epic
>          Components: Beans, Decorators, Interceptors, Resolution
>    Affects Versions: 2.0-EDR1
>            Reporter: Rogerio Liesenfeld
>
> The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.
> With this I mean:
> 1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
> 2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]).
> 3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.
> Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:
> {code}
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = businessOp.getFinalData();
> {code}
> ... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).
> Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).
> For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.
> Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 24 10:34:02 2015
From: issues at jboss.org (George Gastaldi (JIRA))
Date: Fri, 24 Jul 2015 10:34:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
 decorators and interceptors on "new-ed" objects
In-Reply-To: <JIRA.12579311.1437747419000@Atlassian.JIRA>
References: <JIRA.12579311.1437747419000@Atlassian.JIRA>
	<JIRA.12579311.1437747419000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579311.1437747419000.148742.1437748442760@Atlassian.JIRA>


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

George Gastaldi commented on CDI-552:
-------------------------------------

CDI provides a  {{CDI.instance().select(MyBusinessService.class).get()}} to return an object with resolved injections. 
By using {{new}}, the lifecycle scope is no longer controlled by the CDI container so I am not sure CDI implementations can do that.

> Add support for injection, decorators and interceptors on "new-ed" objects
> --------------------------------------------------------------------------
>
>                 Key: CDI-552
>                 URL: https://issues.jboss.org/browse/CDI-552
>             Project: CDI Specification Issues
>          Issue Type: Epic
>          Components: Beans, Decorators, Interceptors, Resolution
>    Affects Versions: 2.0-EDR1
>            Reporter: Rogerio Liesenfeld
>
> The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.
> With this I mean:
> 1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
> 2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]).
> 3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.
> Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:
> {code}
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = businessOp.getFinalData();
> {code}
> ... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).
> Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).
> For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.
> Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 24 11:02:04 2015
From: issues at jboss.org (Rogerio Liesenfeld (JIRA))
Date: Fri, 24 Jul 2015 11:02:04 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
 decorators and interceptors on "new-ed" objects
In-Reply-To: <JIRA.12579311.1437747419000@Atlassian.JIRA>
References: <JIRA.12579311.1437747419000@Atlassian.JIRA>
	<JIRA.12579311.1437747419000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579311.1437747419000.148848.1437750124557@Atlassian.JIRA>


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

Rogerio Liesenfeld commented on CDI-552:
----------------------------------------

The CDI container can still manage objects created with {{new}}, provided the constructors of the class are instrumented (through a java.lang.instrument.ClassFileTransformer installed at container startup - several tools already do this kind of thing). 

The class file transformer would, basically, insert a call to a container method similar to BeanManager#resolve, at the end of every constructor in an eligible class. This would result in the @Inject/etc. fields being properly set in the bean instance that was just new-ed.

Application of decorators and interceptors could be implemented in a similar way, by transforming the bytecode of methods in the bean class to incluide the necessary before/after calls.

Essentially, this is a wholy different approach to implement a CDI container. Rather than creating a proxy class that implements an interface, or a proxy subclass, the original user classes would go through bytecode transformations. Beyond avoid the limitations in the current approach, this would also improve the user experience when using the Java debugger, since there would no longer be generated proxy objects or subclasses to get in the way. It would also, I believe, improve performance.

> Add support for injection, decorators and interceptors on "new-ed" objects
> --------------------------------------------------------------------------
>
>                 Key: CDI-552
>                 URL: https://issues.jboss.org/browse/CDI-552
>             Project: CDI Specification Issues
>          Issue Type: Epic
>          Components: Beans, Decorators, Interceptors, Resolution
>    Affects Versions: 2.0-EDR1
>            Reporter: Rogerio Liesenfeld
>
> The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.
> With this I mean:
> 1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
> 2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]).
> 3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.
> Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:
> {code}
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = businessOp.getFinalData();
> {code}
> ... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).
> Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).
> For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.
> Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 24 11:03:03 2015
From: issues at jboss.org (Rogerio Liesenfeld (JIRA))
Date: Fri, 24 Jul 2015 11:03:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
 decorators and interceptors on "new-ed" objects
In-Reply-To: <JIRA.12579311.1437747419000@Atlassian.JIRA>
References: <JIRA.12579311.1437747419000@Atlassian.JIRA>
	<JIRA.12579311.1437747419000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579311.1437747419000.148856.1437750183638@Atlassian.JIRA>


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

Rogerio Liesenfeld edited comment on CDI-552 at 7/24/15 11:02 AM:
------------------------------------------------------------------

The CDI container can still manage objects created with {{new}}, provided the constructors of the class are instrumented (through a java.lang.instrument.ClassFileTransformer installed at container startup - several tools already do this kind of thing). 

The class file transformer would, basically, insert a call to a container method similar to BeanManager#resolve, at the end of every constructor in an eligible class. This would result in the @Inject/etc. fields being properly set in the bean instance that was just new-ed.

Application of decorators and interceptors could be implemented in a similar way, by transforming the bytecode of methods in the bean class to include the necessary before/after calls.

Essentially, this is a wholy different approach to implement a CDI container. Rather than creating a proxy class that implements an interface, or a proxy subclass, the original user classes would go through bytecode transformations. Beyond avoid the limitations in the current approach, this would also improve the user experience when using the Java debugger, since there would no longer be generated proxy objects or subclasses to get in the way. It would also, I believe, improve performance.


was (Author: rliesenfeld2):
The CDI container can still manage objects created with {{new}}, provided the constructors of the class are instrumented (through a java.lang.instrument.ClassFileTransformer installed at container startup - several tools already do this kind of thing). 

The class file transformer would, basically, insert a call to a container method similar to BeanManager#resolve, at the end of every constructor in an eligible class. This would result in the @Inject/etc. fields being properly set in the bean instance that was just new-ed.

Application of decorators and interceptors could be implemented in a similar way, by transforming the bytecode of methods in the bean class to incluide the necessary before/after calls.

Essentially, this is a wholy different approach to implement a CDI container. Rather than creating a proxy class that implements an interface, or a proxy subclass, the original user classes would go through bytecode transformations. Beyond avoid the limitations in the current approach, this would also improve the user experience when using the Java debugger, since there would no longer be generated proxy objects or subclasses to get in the way. It would also, I believe, improve performance.

> Add support for injection, decorators and interceptors on "new-ed" objects
> --------------------------------------------------------------------------
>
>                 Key: CDI-552
>                 URL: https://issues.jboss.org/browse/CDI-552
>             Project: CDI Specification Issues
>          Issue Type: Epic
>          Components: Beans, Decorators, Interceptors, Resolution
>    Affects Versions: 2.0-EDR1
>            Reporter: Rogerio Liesenfeld
>
> The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.
> With this I mean:
> 1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
> 2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]).
> 3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.
> Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:
> {code}
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = businessOp.getFinalData();
> {code}
> ... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).
> Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).
> For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.
> Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 24 11:03:04 2015
From: issues at jboss.org (Rogerio Liesenfeld (JIRA))
Date: Fri, 24 Jul 2015 11:03:04 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
 decorators and interceptors on "new-ed" objects
In-Reply-To: <JIRA.12579311.1437747419000@Atlassian.JIRA>
References: <JIRA.12579311.1437747419000@Atlassian.JIRA>
	<JIRA.12579311.1437747419000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579311.1437747419000.148861.1437750184074@Atlassian.JIRA>


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

Rogerio Liesenfeld edited comment on CDI-552 at 7/24/15 11:03 AM:
------------------------------------------------------------------

The CDI container can still manage objects created with {{new}}, provided the constructors of the class are instrumented (through a java.lang.instrument.ClassFileTransformer installed at container startup - several tools already do this kind of thing). 

The class file transformer would, basically, insert a call to a container method similar to BeanManager#resolve, at the end of every constructor in an eligible class. This would result in the @Inject/etc. fields being properly set in the bean instance that was just new-ed.

Application of decorators and interceptors could be implemented in a similar way, by transforming the bytecode of methods in the bean class to include the necessary before/after calls.

Essentially, this is a wholly different approach to implement a CDI container. Rather than creating a proxy class that implements an interface, or a proxy subclass, the original user classes would go through bytecode transformations. Beyond avoid the limitations in the current approach, this would also improve the user experience when using the Java debugger, since there would no longer be generated proxy objects or subclasses to get in the way. It would also, I believe, improve performance.


was (Author: rliesenfeld2):
The CDI container can still manage objects created with {{new}}, provided the constructors of the class are instrumented (through a java.lang.instrument.ClassFileTransformer installed at container startup - several tools already do this kind of thing). 

The class file transformer would, basically, insert a call to a container method similar to BeanManager#resolve, at the end of every constructor in an eligible class. This would result in the @Inject/etc. fields being properly set in the bean instance that was just new-ed.

Application of decorators and interceptors could be implemented in a similar way, by transforming the bytecode of methods in the bean class to include the necessary before/after calls.

Essentially, this is a wholy different approach to implement a CDI container. Rather than creating a proxy class that implements an interface, or a proxy subclass, the original user classes would go through bytecode transformations. Beyond avoid the limitations in the current approach, this would also improve the user experience when using the Java debugger, since there would no longer be generated proxy objects or subclasses to get in the way. It would also, I believe, improve performance.

> Add support for injection, decorators and interceptors on "new-ed" objects
> --------------------------------------------------------------------------
>
>                 Key: CDI-552
>                 URL: https://issues.jboss.org/browse/CDI-552
>             Project: CDI Specification Issues
>          Issue Type: Epic
>          Components: Beans, Decorators, Interceptors, Resolution
>    Affects Versions: 2.0-EDR1
>            Reporter: Rogerio Liesenfeld
>
> The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.
> With this I mean:
> 1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
> 2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]).
> 3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.
> Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:
> {code}
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = businessOp.getFinalData();
> {code}
> ... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).
> Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).
> For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.
> Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri Jul 24 11:04:02 2015
From: issues at jboss.org (Rogerio Liesenfeld (JIRA))
Date: Fri, 24 Jul 2015 11:04:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
 decorators and interceptors on "new-ed" objects
In-Reply-To: <JIRA.12579311.1437747419000@Atlassian.JIRA>
References: <JIRA.12579311.1437747419000@Atlassian.JIRA>
	<JIRA.12579311.1437747419000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579311.1437747419000.148863.1437750242341@Atlassian.JIRA>


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

Rogerio Liesenfeld edited comment on CDI-552 at 7/24/15 11:03 AM:
------------------------------------------------------------------

The CDI container can still manage objects created with {{new}}, provided the constructors of the class are instrumented (through a java.lang.instrument.ClassFileTransformer installed at container startup - several tools already do this kind of thing). 

The class file transformer would, basically, insert a call to a container method similar to BeanManager#resolve, at the end of every constructor in an eligible class. This would result in the @Inject/etc. fields being properly set in the bean instance that was just new-ed.

Application of decorators and interceptors could be implemented in a similar way, by transforming the bytecode of methods in the bean class to include the necessary before/after calls.

Essentially, this is a wholly different approach to implement a CDI container. Rather than creating a proxy class that implements an interface, or a proxy subclass, the original user classes would go through bytecode transformations. Beyond avoiding the limitations in the current approach, this would also improve the user experience when using the Java debugger, since there would no longer be generated proxy objects or subclasses to get in the way. It would also, I believe, improve performance.


was (Author: rliesenfeld2):
The CDI container can still manage objects created with {{new}}, provided the constructors of the class are instrumented (through a java.lang.instrument.ClassFileTransformer installed at container startup - several tools already do this kind of thing). 

The class file transformer would, basically, insert a call to a container method similar to BeanManager#resolve, at the end of every constructor in an eligible class. This would result in the @Inject/etc. fields being properly set in the bean instance that was just new-ed.

Application of decorators and interceptors could be implemented in a similar way, by transforming the bytecode of methods in the bean class to include the necessary before/after calls.

Essentially, this is a wholly different approach to implement a CDI container. Rather than creating a proxy class that implements an interface, or a proxy subclass, the original user classes would go through bytecode transformations. Beyond avoid the limitations in the current approach, this would also improve the user experience when using the Java debugger, since there would no longer be generated proxy objects or subclasses to get in the way. It would also, I believe, improve performance.

> Add support for injection, decorators and interceptors on "new-ed" objects
> --------------------------------------------------------------------------
>
>                 Key: CDI-552
>                 URL: https://issues.jboss.org/browse/CDI-552
>             Project: CDI Specification Issues
>          Issue Type: Epic
>          Components: Beans, Decorators, Interceptors, Resolution
>    Affects Versions: 2.0-EDR1
>            Reporter: Rogerio Liesenfeld
>
> The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.
> With this I mean:
> 1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
> 2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]).
> 3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.
> Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:
> {code}
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = businessOp.getFinalData();
> {code}
> ... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).
> Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).
> For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.
> Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Sun Jul 26 08:47:02 2015
From: issues at jboss.org (Sven Linstaedt (JIRA))
Date: Sun, 26 Jul 2015 08:47:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
 decorators and interceptors on "new-ed" objects
In-Reply-To: <JIRA.12579311.1437747419000@Atlassian.JIRA>
References: <JIRA.12579311.1437747419000@Atlassian.JIRA>
	<JIRA.12579311.1437747419000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579311.1437747419000.149969.1437914822650@Atlassian.JIRA>


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

Sven Linstaedt commented on CDI-552:
------------------------------------

Most of theses requirements are already possible using some factory delegation:

In order to archive injection with "manually" programmatically provided arguments, I would create a dedicated factory, which is fully managed by CDI and 
* has all of {{MyBusinessService::new}} injected dependencies already injected via {{Instance<X>}}
* has a create method with all manually provided parameters, which
* creates are new MyBusinessService by invoking the beforementioned constructor with manually provided arguments and {{instance.get()}} provided dependencies
* "remembers" all via created dependencies in some map (in case of dependent scoped dependencies)
* use a {{InjectionTarget<MyBusinessService>}} and for injecting all remaining dependencies and calling it's {{@PostConstruct}} method, just as it is done in {{javax.enterprise.inject.spi.Unmanaged}}.

As the application is going to manage the the "bean's" lifecycle itself (via {{new}}) like for dependent scoped beans, it should also be responsible for destroying it explicitly (normally one would call some destroying method like {{AutoClosable}} and/or simply wait for the GC). So the factory should 
* have some destroy method for {{MyBusinessService}}
* having it's {{@PreDestroy}} method called via {{InjectionTarget<MyBusinessService>}} 
* having all of MyBusinessService created dependencies destroyed via {{Instance::destroy}}

In order to get AOP support you would need some class enhancement as mentioned by Rogerio, because decorators and interceptors are attached to the instance itself and not to some kind of proxy instance.

> Add support for injection, decorators and interceptors on "new-ed" objects
> --------------------------------------------------------------------------
>
>                 Key: CDI-552
>                 URL: https://issues.jboss.org/browse/CDI-552
>             Project: CDI Specification Issues
>          Issue Type: Epic
>          Components: Beans, Decorators, Interceptors, Resolution
>    Affects Versions: 2.0-EDR1
>            Reporter: Rogerio Liesenfeld
>
> The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.
> With this I mean:
> 1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
> 2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]).
> 3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.
> Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:
> {code}
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = businessOp.getFinalData();
> {code}
> ... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).
> Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).
> For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.
> Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Mon Jul 27 05:01:02 2015
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Mon, 27 Jul 2015 05:01:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-549) Unnecessary statement in "8.1.2.
 Decorator delegate injection points" ?
In-Reply-To: <JIRA.12579015.1437630045000@Atlassian.JIRA>
References: <JIRA.12579015.1437630045000@Atlassian.JIRA>
	<JIRA.12579015.1437630045000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579015.1437630045000.150921.1437987662312@Atlassian.JIRA>


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

Emily Jiang commented on CDI-549:
---------------------------------

My view is it does not harm to list them as we should not assume everyone who reads the specification know the full list of the injection points. As far as I know, some people just search particular phrases to verify whether the test application is valid or not. 

> Unnecessary statement in "8.1.2. Decorator delegate injection points" ?
> -----------------------------------------------------------------------
>
>                 Key: CDI-549
>                 URL: https://issues.jboss.org/browse/CDI-549
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Decorators
>    Affects Versions: 1.2.Final
>            Reporter: Tomas Remes
>            Priority: Minor
>
> Decorators cannot declare observers, producers and disposers according to:
> {quote}
> Interceptors and decorators may not declare producer methods. If an interceptor or decorator has a method annotated @Produces , the container automatically detects the problem and treats it as a definition error.
> {quote}
> and
> {quote}
> Interceptors and decorators may not declare observer methods. If an interceptor or decorator has a method with a parameter annotated @Observes , the container automatically detects the problem
> and treats it as a definition error.
> {quote}
> The question is whether following restriction (basically second sentence) is unnecessary because all conditions (in which this could happen) are already excluded in the above restrictions. 
> {quote}
> The delegate injection point must be an injected field, initializer method parameter or bean constructor method parameter. If an injection point that is not an injected field, initializer method parameter or bean constructor method parameter is annotated @Delegate , the container
> automatically detects the problem and treats it as a definition error.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From antoine at sabot-durand.net  Tue Jul 28 05:25:41 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 28 Jul 2015 09:25:41 +0000
Subject: [cdi-dev] No meeting today
Message-ID: <CABu-YBRV2yrNJJ61KOF2Fecn_Zw__eLOeREuVwva0Kt7JSLhng@mail.gmail.com>

Hi guys,

Won't be available today: my daughter will leave surgery at the same time.

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150728/3d3f40ec/attachment.html 

From issues at jboss.org  Wed Jul 29 09:13:01 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 29 Jul 2015 09:13:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-553) Chapter 10.5.3. Observer method
 invocation context should probably be in EE part
In-Reply-To: <JIRA.12579758.1438175534000@Atlassian.JIRA>
References: <JIRA.12579758.1438175534000@Atlassian.JIRA>
	<JIRA.12579758.1438175534647@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579758.1438175534000.158156.1438175581966@Atlassian.JIRA>

Tomas Remes created CDI-553:
-------------------------------

             Summary: Chapter 10.5.3. Observer method invocation context should probably be in EE part
                 Key: CDI-553
                 URL: https://issues.jboss.org/browse/CDI-553
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Tomas Remes


Chapter {{10.5.3. Observer method invocation context}} mainly speaks about transaction context and security context. AFAIK security context is a Java EE term and can be tested using EJBs. 
So I think this chapter should be moved (or possibly split up) to the EE part of spec. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From antoine at sabot-durand.net  Thu Jul 30 09:11:34 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 30 Jul 2015 13:11:34 +0000
Subject: [cdi-dev] O Captain! My Captain!
Message-ID: <CABu-YBRV=5Y9iUjhPLy_cnsqGKMqb74YCJeXrL1D_rENM-6dEQ@mail.gmail.com>

Hi Guys,

Just to inform you that Pete is stepping down his spec lead role on CDI as
he's going to take new responsibilities at Red Hat.

I think that we can thank him for the awesome work he did on CDI from the
beginning and wish him good luck for his new adventure in IT.

Goodbye Pete, and thanks for all the Beans ;)

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150730/307e06a9/attachment.html 

From ggastald at redhat.com  Thu Jul 30 09:21:07 2015
From: ggastald at redhat.com (George Gastaldi)
Date: Thu, 30 Jul 2015 09:21:07 -0400 (EDT)
Subject: [cdi-dev] O Captain! My Captain!
In-Reply-To: <CABu-YBRV=5Y9iUjhPLy_cnsqGKMqb74YCJeXrL1D_rENM-6dEQ@mail.gmail.com>
References: <CABu-YBRV=5Y9iUjhPLy_cnsqGKMqb74YCJeXrL1D_rENM-6dEQ@mail.gmail.com>
Message-ID: <f0wj1mc4ag1ilgsd5g1g5xyx.1438262447966@email.android.com>

Thanks Pete. You did an amazing job indeed. Long live the new king, Antoine ! :)<div>
</div><div>
</div><div>-------- Mensagem original --------</div><div>De: Antoine Sabot-Durand <antoine at sabot-durand.net> </div><div>Data: 30/07/2015  10:12  (GMT-03:00) </div><div>Para: cdi-dev <cdi-dev at lists.jboss.org> </div><div>Assunto: [cdi-dev] O Captain! My Captain! </div><div>
</div>Hi Guys,

Just to inform you that Pete is stepping down his spec lead role on CDI as
he's going to take new responsibilities at Red Hat.

I think that we can thank him for the awesome work he did on CDI from the
beginning and wish him good luck for his new adventure in IT.

Goodbye Pete, and thanks for all the Beans ;)

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150730/4ec8b218/attachment.html 
-------------- next part --------------
_______________________________________________
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 reza.rahman at oracle.com  Thu Jul 30 09:27:53 2015
From: reza.rahman at oracle.com (Reza Rahman)
Date: Thu, 30 Jul 2015 09:27:53 -0400
Subject: [cdi-dev] O Captain! My Captain!
In-Reply-To: <f0wj1mc4ag1ilgsd5g1g5xyx.1438262447966@email.android.com>
References: <CABu-YBRV=5Y9iUjhPLy_cnsqGKMqb74YCJeXrL1D_rENM-6dEQ@mail.gmail.com>
	<f0wj1mc4ag1ilgsd5g1g5xyx.1438262447966@email.android.com>
Message-ID: <2E6E3FE2-F24A-4648-B608-80E79B3EE910@oracle.com>

In net, I personally this this is for the better for everyone.

> On Jul 30, 2015, at 9:21 AM, George Gastaldi <ggastald at redhat.com> wrote:
> 
> Thanks Pete. You did an amazing job indeed. Long live the new king, Antoine ! :)
> 
> 
> -------- Mensagem original --------
> De: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Data: 30/07/2015 10:12 (GMT-03:00)
> Para: cdi-dev <cdi-dev at lists.jboss.org>
> Assunto: [cdi-dev] O Captain! My Captain!
> 
> 
> Hi Guys,
> 
> Just to inform you that Pete is stepping down his spec lead role on CDI as he's going to take new responsibilities at Red Hat.
> 
> I think that we can thank him for the awesome work he did on CDI from the beginning and wish him good luck for his new adventure in IT.
> 
> Goodbye Pete, and thanks for all the Beans ;)
> 
> Antoine
> _______________________________________________
> 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 pmuir at redhat.com  Thu Jul 30 10:00:47 2015
From: pmuir at redhat.com (Pete Muir)
Date: Thu, 30 Jul 2015 15:00:47 +0100
Subject: [cdi-dev] O Captain! My Captain!
In-Reply-To: <CABu-YBRV=5Y9iUjhPLy_cnsqGKMqb74YCJeXrL1D_rENM-6dEQ@mail.gmail.com>
References: <CABu-YBRV=5Y9iUjhPLy_cnsqGKMqb74YCJeXrL1D_rENM-6dEQ@mail.gmail.com>
Message-ID: <DB3E71F6-749D-439C-874E-089A5A826813@redhat.com>

Thank you everyone for all your help over the last few years, I?ve really enjoyed CDI, and tried to hang on as long as I could. You?ll probably have noticed I?ve barely been around for the last 6 months, and so it?s definitely for the best that I leave it in the very capable hands of Antoine :-)

Pete

> On 30 Jul 2015, at 14:11, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
> 
> Hi Guys,
> 
> Just to inform you that Pete is stepping down his spec lead role on CDI as he's going to take new responsibilities at Red Hat.
> 
> I think that we can thank him for the awesome work he did on CDI from the beginning and wish him good luck for his new adventure in IT.
> 
> Goodbye Pete, and thanks for all the Beans ;)
> 
> Antoine
> _______________________________________________
> 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.