From antoine at sabot-durand.net Mon Sep 1 05:47:52 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 01 Sep 2014 09:47:52 +0000 Subject: [cdi-dev] Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - 19:00 (ASD Perso) Message-ID: <001a11c38b1c7c974f0501fde5be@google.com> You have been invited to the following event. Title: CDI meeting When: Wed 3 Sep 2014 18:00 - 19:00 Paris Where: #cdi-dev on freenode IRC Video call: https://plus.google.com/hangouts/_/sabot-durand.net/antoine Calendar: ASD Perso Who: * Antoine Sabot-Durand- organiser * cdi-dev at lists.jboss.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I2OGFwN2EyMTYyb2sgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZmFhYWI3ZDMwMjU3NzlhOTM2MDIzMzExZWYwYmEwYmRlOWQ5ZjdlNg&ctz=Europe/Paris&hl=en_GB Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev at lists.jboss.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively, you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1074 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1102 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0001.bin From issues at jboss.org Mon Sep 1 05:55:00 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 1 Sep 2014 05:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-45: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From omeuefilipe at gmail.com Mon Sep 1 09:24:37 2014 From: omeuefilipe at gmail.com (Filipe Portes) Date: Mon, 1 Sep 2014 10:24:37 -0300 Subject: [cdi-dev] Spec launch meeting and CDI weekly meeting In-Reply-To: References: <5401ae92.0153b40a.4f24.ffff9183@mx.google.com> Message-ID: here in brazil 16:00 UTC equals to 1:00 pm, so it's pretty good. On Sat, Aug 30, 2014 at 9:00 AM, Mark Paluch wrote: > Either way is fine with me. In general 16:00 UTC is a good choice since it > seems not to be mid-might for anyone that is involved. > > Best regards, Mark > > Am 30.08.2014 um 12:53 schrieb Thorben Janssen : > > Wednesday at the same time is fine for me. > Do you want to shift all meetings or only this one? > > Regards, > Thorben > ------------------------------ > Von: Antoine Sabot-Durand > Gesendet: ?30.?08.?2014 12:18 > An: John D. Ament > Cc: cdi-dev > Betreff: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting > > Hi John, > > Sorry to have missed that. According to Pete, French are holidays > specialists. I guess I have to improve my expertise in this domain ;). > > Is it ok for everybody to switch the meeting on Wednesday at the same > time ? If there ware no objection I will send you an invitation Monday. > > > > Antoine > > Le 29 ao?t 2014 ? 18:53, John D. Ament a ?crit : > > Could it be pushed to later in the week? Monday's a holiday in the US. > > > On Fri, Aug 29, 2014 at 9:32 AM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi All, >> >> On CDI 1.1, we use to have a weekly meeting each monday at 16:00 UTC >> (that?s 9:00 am PDT, 6:00 pm CEST and 9:30 pm IST). It?s hard to find a >> time slot that please everybody (from US West Coast to India), so Ir >> propose we keep this track. Now, if you have issue with this slot (if you >> live in New Zealand or Australia) say it and we?ll try to figure out a >> better slot (even if there?s no ideal one). >> >> The meeting place is the IRC channel and last one hour. We use an IRC bot >> (jbott) to keep track of meeting minutes for the record or people unable to >> attend the meeting. You can get familiarised with BOT commands here : >> https://wiki.debian.org/MeetBot >> >> So I propose we have our JSR launch meeting next monday (sept 1st) with >> the following agenda : >> >> - Discussion on the working method and tools used (mainly do we use >> Google Drive or Github with Asciidoc for working doc) >> - Discussion on each workshop I mentioned in my previous post and missing >> workshop >> * Workshop teams >> * Workflow chosen >> * estimated deadline (hard to say since we don?t know our workforce, but >> will be refined later) >> - Q & A if we still have time >> >> Note that It think we should avoid talking about specific content of >> workshop except if you think things are missing or that we could forgot >> them. >> If you want to see other points in the agenda let me know. >> >> I?m thrilled to start this great project with you guys. >> >> 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. > > > > _______________________________________________ > 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. > -- Filipe Portes - @filipeportes Senior Java EE/Web JUGLeader Gojava - @gojava -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/attachment-0001.html From radhakrishnan.mohan at gmail.com Mon Sep 1 10:45:38 2014 From: radhakrishnan.mohan at gmail.com (Mohan Radhakrishnan) Date: Mon, 1 Sep 2014 20:15:38 +0530 Subject: [cdi-dev] Fwd: Spec launch meeting and CDI weekly meeting In-Reply-To: References: <5401ae92.0153b40a.4f24.ffff9183@mx.google.com> Message-ID: Missed the list. ---------- Forwarded message ---------- From: Mohan Radhakrishnan Date: Mon, Sep 1, 2014 at 8:15 PM Subject: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting To: Filipe Portes >>weekly meeting each monday at 16:00 UTC (that?s 9:00 am PDT, 6:00 pm CEST and 9:30 pm IST) What is the date ? :-) It will be 2nd September in India. Mohan On Mon, Sep 1, 2014 at 6:54 PM, Filipe Portes wrote: > here in brazil 16:00 UTC equals to 1:00 pm, so it's pretty good. > > > On Sat, Aug 30, 2014 at 9:00 AM, Mark Paluch wrote: > >> Either way is fine with me. In general 16:00 UTC is a good choice since >> it seems not to be mid-might for anyone that is involved. >> >> Best regards, Mark >> >> Am 30.08.2014 um 12:53 schrieb Thorben Janssen : >> >> Wednesday at the same time is fine for me. >> Do you want to shift all meetings or only this one? >> >> Regards, >> Thorben >> ------------------------------ >> Von: Antoine Sabot-Durand >> Gesendet: ?30.?08.?2014 12:18 >> An: John D. Ament >> Cc: cdi-dev >> Betreff: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting >> >> Hi John, >> >> Sorry to have missed that. According to Pete, French are holidays >> specialists. I guess I have to improve my expertise in this domain ;). >> >> Is it ok for everybody to switch the meeting on Wednesday at the same >> time ? If there ware no objection I will send you an invitation Monday. >> >> >> >> Antoine >> >> Le 29 ao?t 2014 ? 18:53, John D. Ament a ?crit >> : >> >> Could it be pushed to later in the week? Monday's a holiday in the US. >> >> >> On Fri, Aug 29, 2014 at 9:32 AM, Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>> Hi All, >>> >>> On CDI 1.1, we use to have a weekly meeting each monday at 16:00 UTC >>> (that?s 9:00 am PDT, 6:00 pm CEST and 9:30 pm IST). It?s hard to find a >>> time slot that please everybody (from US West Coast to India), so Ir >>> propose we keep this track. Now, if you have issue with this slot (if you >>> live in New Zealand or Australia) say it and we?ll try to figure out a >>> better slot (even if there?s no ideal one). >>> >>> The meeting place is the IRC channel and last one hour. We use an IRC >>> bot (jbott) to keep track of meeting minutes for the record or people >>> unable to attend the meeting. You can get familiarised with BOT commands >>> here : >>> https://wiki.debian.org/MeetBot >>> >>> So I propose we have our JSR launch meeting next monday (sept 1st) with >>> the following agenda : >>> >>> - Discussion on the working method and tools used (mainly do we use >>> Google Drive or Github with Asciidoc for working doc) >>> - Discussion on each workshop I mentioned in my previous post and >>> missing workshop >>> * Workshop teams >>> * Workflow chosen >>> * estimated deadline (hard to say since we don?t know our workforce, but >>> will be refined later) >>> - Q & A if we still have time >>> >>> Note that It think we should avoid talking about specific content of >>> workshop except if you think things are missing or that we could forgot >>> them. >>> If you want to see other points in the agenda let me know. >>> >>> I?m thrilled to start this great project with you guys. >>> >>> 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. >> >> >> >> _______________________________________________ >> 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. >> > > > > -- > Filipe Portes - @filipeportes > Senior Java EE/Web > JUGLeader Gojava - @gojava > > _______________________________________________ > 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/20140901/3ee298b7/attachment.html From radhakrishnan.mohan at gmail.com Mon Sep 1 10:48:56 2014 From: radhakrishnan.mohan at gmail.com (Mohan Radhakrishnan) Date: Mon, 1 Sep 2014 20:18:56 +0530 Subject: [cdi-dev] Spec launch meeting and CDI weekly meeting In-Reply-To: References: <5401ae92.0153b40a.4f24.ffff9183@mx.google.com> Message-ID: Sorry. Just noticed the invitation. Wed Sep 3, 2014 9:30pm ? 10:30pm (IST) Mohan On Mon, Sep 1, 2014 at 8:15 PM, Mohan Radhakrishnan < radhakrishnan.mohan at gmail.com> wrote: > > Missed the list. > > ---------- Forwarded message ---------- > From: Mohan Radhakrishnan > Date: Mon, Sep 1, 2014 at 8:15 PM > Subject: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting > To: Filipe Portes > > > >>weekly meeting each monday at 16:00 UTC (that?s 9:00 am PDT, 6:00 pm > CEST and 9:30 pm IST) > > What is the date ? :-) It will be 2nd September in India. > > Mohan > > > On Mon, Sep 1, 2014 at 6:54 PM, Filipe Portes > wrote: > >> here in brazil 16:00 UTC equals to 1:00 pm, so it's pretty good. >> >> >> On Sat, Aug 30, 2014 at 9:00 AM, Mark Paluch wrote: >> >>> Either way is fine with me. In general 16:00 UTC is a good choice since >>> it seems not to be mid-might for anyone that is involved. >>> >>> Best regards, Mark >>> >>> Am 30.08.2014 um 12:53 schrieb Thorben Janssen : >>> >>> Wednesday at the same time is fine for me. >>> Do you want to shift all meetings or only this one? >>> >>> Regards, >>> Thorben >>> ------------------------------ >>> Von: Antoine Sabot-Durand >>> Gesendet: ?30.?08.?2014 12:18 >>> An: John D. Ament >>> Cc: cdi-dev >>> Betreff: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting >>> >>> Hi John, >>> >>> Sorry to have missed that. According to Pete, French are holidays >>> specialists. I guess I have to improve my expertise in this domain ;). >>> >>> Is it ok for everybody to switch the meeting on Wednesday at the same >>> time ? If there ware no objection I will send you an invitation Monday. >>> >>> >>> >>> Antoine >>> >>> Le 29 ao?t 2014 ? 18:53, John D. Ament a >>> ?crit : >>> >>> Could it be pushed to later in the week? Monday's a holiday in the US. >>> >>> >>> On Fri, Aug 29, 2014 at 9:32 AM, Antoine Sabot-Durand < >>> antoine at sabot-durand.net> wrote: >>> >>>> Hi All, >>>> >>>> On CDI 1.1, we use to have a weekly meeting each monday at 16:00 UTC >>>> (that?s 9:00 am PDT, 6:00 pm CEST and 9:30 pm IST). It?s hard to find a >>>> time slot that please everybody (from US West Coast to India), so Ir >>>> propose we keep this track. Now, if you have issue with this slot (if you >>>> live in New Zealand or Australia) say it and we?ll try to figure out a >>>> better slot (even if there?s no ideal one). >>>> >>>> The meeting place is the IRC channel and last one hour. We use an IRC >>>> bot (jbott) to keep track of meeting minutes for the record or people >>>> unable to attend the meeting. You can get familiarised with BOT commands >>>> here : >>>> https://wiki.debian.org/MeetBot >>>> >>>> So I propose we have our JSR launch meeting next monday (sept 1st) with >>>> the following agenda : >>>> >>>> - Discussion on the working method and tools used (mainly do we use >>>> Google Drive or Github with Asciidoc for working doc) >>>> - Discussion on each workshop I mentioned in my previous post and >>>> missing workshop >>>> * Workshop teams >>>> * Workflow chosen >>>> * estimated deadline (hard to say since we don?t know our workforce, >>>> but will be refined later) >>>> - Q & A if we still have time >>>> >>>> Note that It think we should avoid talking about specific content of >>>> workshop except if you think things are missing or that we could forgot >>>> them. >>>> If you want to see other points in the agenda let me know. >>>> >>>> I?m thrilled to start this great project with you guys. >>>> >>>> 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. >>> >>> >>> >>> _______________________________________________ >>> 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. >>> >> >> >> >> -- >> Filipe Portes - @filipeportes >> Senior Java EE/Web >> JUGLeader Gojava - @gojava >> >> _______________________________________________ >> 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/20140901/b7fef6bc/attachment-0001.html From antoine at sabot-durand.net Mon Sep 1 11:21:37 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 1 Sep 2014 17:21:37 +0200 Subject: [cdi-dev] Writing about CDI 2.0 and work in EG In-Reply-To: References: Message-ID: Hi Thorben, I?m answering on the mailing list since others can be interested. Everything around the specification will be transparent end publicly available. On the JCP side this transparency is describe in version 2.9 of JCP process document : https://jcp.org/en/procedures/jcp2_9#1 . On our side (Red Hat) we treat this project as any other ASL2 open Source project. JSPA signature and legal mention added to the ML footer and IRC are only here to avoid future Intellectual Property dispute. So if you want to describe what?s happening with CDI 2.0 EG, you?re very welcome, since it?ll help for the JSR communication. Regards, Antoine > Le 1 sept. 2014 ? 16:19, Thorben Janssen a ?crit : > > Hey Antoine, > > are there any limitations on writing about our work in the expert group? > Everything is open and published under a open source license. So from my point of view, there should be no limitations. Am I missing something? > > There are two things I am currently thinking about: > - The start of the expert group would be an interesting topic for a blog post. > - The ongoing work might be an interesting topic for an article in the german print magazine "Java Magazin". I got 4 month to write my current article and it will be published 1,5 month later. So I would submit the proposal next month and expect to get a deadline for beginning of next year. > > What do you think? > > Regards, > Thorben > > -- > Thorben Janssen > > @thjanssen123 > www.thoughts-on-java.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/84bad6e0/attachment.html From issues at jboss.org Mon Sep 1 11:35:00 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 1 Sep 2014 11:35:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997509#comment-12997509 ] Antonin Stefanutti commented on CDI-45: --------------------------------------- >From my understanding, that need is met with [{{javax.enterprise.inject.Instance}}|http://docs.oracle.com/javaee/7/api/javax/enterprise/inject/Instance.html]: {code} @Inject Instance bean; if (!bean.isUnsatisfied()) bean.get(); {code} What would be the added value of the {{@Optional}} approach compared to the {{Instance}} concept. Besides, that approach would lead to having potential NPE or to check against nullity which is not very elegant. That being said, with the CDI 2.0 / Java 8 enhancement stream, [{{java.util.Optional}}|http://docs.oracle.com/javase/8/docs/api/java/util/Optional.html] could be automatically supported: {code} @Inject Optional bean; bean.isPresent(); bean.orElse(...); {code} > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 11:36:01 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 1 Sep 2014 11:36:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997509#comment-12997509 ] Antonin Stefanutti edited comment on CDI-45 at 9/1/14 11:35 AM: ---------------------------------------------------------------- >From my understanding, that need is met with [{{javax.enterprise.inject.Instance}}|http://docs.oracle.com/javaee/7/api/javax/enterprise/inject/Instance.html]: {code} @Inject Instance bean; if (!bean.isUnsatisfied()) bean.get(); {code} What would be the added value of the {{@Optional}} approach compared to the {{Instance}} concept? Besides, that approach would lead to having potential NPE or to check against nullity which is not very elegant. That being said, with the CDI 2.0 / Java 8 enhancement stream, [{{java.util.Optional}}|http://docs.oracle.com/javase/8/docs/api/java/util/Optional.html] could be automatically supported: {code} @Inject Optional bean; bean.isPresent(); bean.orElse(...); {code} was (Author: stefanutti): >From my understanding, that need is met with [{{javax.enterprise.inject.Instance}}|http://docs.oracle.com/javaee/7/api/javax/enterprise/inject/Instance.html]: {code} @Inject Instance bean; if (!bean.isUnsatisfied()) bean.get(); {code} What would be the added value of the {{@Optional}} approach compared to the {{Instance}} concept. Besides, that approach would lead to having potential NPE or to check against nullity which is not very elegant. That being said, with the CDI 2.0 / Java 8 enhancement stream, [{{java.util.Optional}}|http://docs.oracle.com/javase/8/docs/api/java/util/Optional.html] could be automatically supported: {code} @Inject Optional bean; bean.isPresent(); bean.orElse(...); {code} > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 14:45:00 2014 From: issues at jboss.org (Thorben Janssen (JIRA)) Date: Mon, 1 Sep 2014 14:45:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997563#comment-12997563 ] Thorben Janssen commented on CDI-45: ------------------------------------ {code}Instance extends Iterable{code} and therefore might contain more than one MyBean instances. It would not be possible to inject only one or no MyBean instances. I like the Java8 Optional idea. It is similar to the existing Instance approach, avoids null checks and fits to the planned Java 8 enhancements. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 14:47:00 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 1 Sep 2014 14:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997564#comment-12997564 ] Romain Manni-Bucau commented on CDI-45: --------------------------------------- But while Optional is not Serializable it would be a mess in EE/CDI context > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 14:57:00 2014 From: issues at jboss.org (Renat Valeev (JIRA)) Date: Mon, 1 Sep 2014 14:57:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997565#comment-12997565 ] Renat Valeev commented on CDI-45: --------------------------------- It should not. Instance is not Serializable as well. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 15:01:02 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 1 Sep 2014 15:01:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997566#comment-12997566 ] Romain Manni-Bucau commented on CDI-45: --------------------------------------- Instance is handled by the containers so adding Optional means forcing the container to serialize it...which means force the container to get its value and ensure it is serializable > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 15:09:00 2014 From: issues at jboss.org (Anatole Tresch (JIRA)) Date: Mon, 1 Sep 2014 15:09:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997568#comment-12997568 ] Anatole Tresch commented on CDI-45: ----------------------------------- I do not think that this would be a feasible approach. This would require all vendors to customize serialization... additionally I would expect other side effects with code that the EE container maybe is not aware of, EE is still running on top of SE. You cannot change SE 8, it is given. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 15:10:00 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 1 Sep 2014 15:10:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997569#comment-12997569 ] Romain Manni-Bucau commented on CDI-45: --------------------------------------- agree, was my point > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 15:12:00 2014 From: issues at jboss.org (Renat Valeev (JIRA)) Date: Mon, 1 Sep 2014 15:12:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997570#comment-12997570 ] Renat Valeev commented on CDI-45: --------------------------------- Ok, then explain how we have now Instance interface and it is not serializable. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 15:14:00 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 1 Sep 2014 15:14:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997571#comment-12997571 ] Romain Manni-Bucau commented on CDI-45: --------------------------------------- {code} class InstanceImpl implements Instance, Serializable {code} that's rely on CDI implementation, Optional can't since the impl is in the JVM > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 15:19:00 2014 From: issues at jboss.org (Renat Valeev (JIRA)) Date: Mon, 1 Sep 2014 15:19:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997573#comment-12997573 ] Renat Valeev commented on CDI-45: --------------------------------- Have not spot that Optional is a class. But approach with @Optional or @Inject(optional=true) will mean that object can be null, which is not good. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 15:24:00 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 1 Sep 2014 15:24:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997574#comment-12997574 ] Romain Manni-Bucau commented on CDI-45: --------------------------------------- Well Instance almost matches this need. Only known issue it has is the fact it doesn't only have isSatisfied(), get() methods so resolution is almost everytimes done lazily which is/can be slow compared to normal injection. Having SingletonInstance with only these methods (and Instance inheriting from it) could solve it but not sure this change can be introduced. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 15:31:01 2014 From: issues at jboss.org (Renat Valeev (JIRA)) Date: Mon, 1 Sep 2014 15:31:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997575#comment-12997575 ] Renat Valeev commented on CDI-45: --------------------------------- I think there could be an interface between Provider and Instance, which will have method isUnsatisfied(). So that way backward compatibility will be preserved. The question is not only of how we declare, but also if the dependecy is ambiguous, should resolution fail for "optional" dependecy? > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 15:32:00 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 1 Sep 2014 15:32:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997576#comment-12997576 ] Romain Manni-Bucau commented on CDI-45: --------------------------------------- sure, IMHO optional injection points have the exact same constraints as normal injection excepted it can be null > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 15:40:00 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 1 Sep 2014 15:40:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997578#comment-12997578 ] Antonin Stefanutti commented on CDI-45: --------------------------------------- Then one potential compromise would be to enrich the existing abstractions, either {{Instance}} or {{Provider}} with the {{Optional}} semantic. For example: {code} @Inject Provider bean; if (bean.isPresent()) bean.get(); {code} In any case, I think that a {{isSatisfied()}} / {{isResolvable()}} method is missing on the {{Instance}} interface when alternatives are enabled for example and that would avoid writing {{!isUnsatisfied() && !isAmbiguous()}}. As per backward compatibility for these interfaces, are they really meant to be implemented aside from the implementations? That would avoid introducing another interface. If not maybe default method in Java 8 could help. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 15:44:00 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 1 Sep 2014 15:44:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997578#comment-12997578 ] Antonin Stefanutti edited comment on CDI-45 at 9/1/14 3:43 PM: --------------------------------------------------------------- Then one potential compromise would be to enrich the existing abstractions, either {{Instance}} or {{Provider}} with the equivalent semantic that of {{Optional}}. For example: {code} @Inject Provider bean; if (bean.isPresent()) bean.get(); {code} In any case, I think that a {{isSatisfied()}} / {{isResolvable()}} method is missing on the {{Instance}} interface when alternatives are enabled for example and that would avoid writing {{!isUnsatisfied() && !isAmbiguous()}}. As per backward compatibility for these interfaces, are they really meant to be implemented aside from the implementations? That would avoid introducing another interface. If not maybe default method in Java 8 could help. was (Author: stefanutti): Then one potential compromise would be to enrich the existing abstractions, either {{Instance}} or {{Provider}} with the {{Optional}} semantic. For example: {code} @Inject Provider bean; if (bean.isPresent()) bean.get(); {code} In any case, I think that a {{isSatisfied()}} / {{isResolvable()}} method is missing on the {{Instance}} interface when alternatives are enabled for example and that would avoid writing {{!isUnsatisfied() && !isAmbiguous()}}. As per backward compatibility for these interfaces, are they really meant to be implemented aside from the implementations? That would avoid introducing another interface. If not maybe default method in Java 8 could help. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 17:15:01 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 1 Sep 2014 17:15:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997578#comment-12997578 ] Antonin Stefanutti edited comment on CDI-45 at 9/1/14 5:14 PM: --------------------------------------------------------------- Then one potential compromise would be to enrich the existing abstractions, either {{Instance}} or {{Provider}} with the equivalent semantic that of {{Optional}}. For example: {code} @Inject Provider bean; if (bean.isPresent()) bean.get(); {code} Or if we think {{Optional}} is a convenient abstraction: {code} @Inject Provider bean; bean.getOptional(); {code} In any case, I think that a {{isSatisfied()}} / {{isResolvable()}} method is missing on the {{Instance}} interface when alternatives are enabled for example and that would avoid writing {{!isUnsatisfied() && !isAmbiguous()}}. As per backward compatibility for these interfaces, are they really meant to be implemented aside from the implementations? That would avoid introducing another interface. If not maybe default method in Java 8 could help. was (Author: stefanutti): Then one potential compromise would be to enrich the existing abstractions, either {{Instance}} or {{Provider}} with the equivalent semantic that of {{Optional}}. For example: {code} @Inject Provider bean; if (bean.isPresent()) bean.get(); {code} In any case, I think that a {{isSatisfied()}} / {{isResolvable()}} method is missing on the {{Instance}} interface when alternatives are enabled for example and that would avoid writing {{!isUnsatisfied() && !isAmbiguous()}}. As per backward compatibility for these interfaces, are they really meant to be implemented aside from the implementations? That would avoid introducing another interface. If not maybe default method in Java 8 could help. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From david_currie at uk.ibm.com Tue Sep 2 11:46:38 2014 From: david_currie at uk.ibm.com (David Currie) Date: Tue, 2 Sep 2014 16:46:38 +0100 Subject: [cdi-dev] Spec launch meeting and CDI weekly meeting In-Reply-To: References: Message-ID: Hi Antoine, My apologies - just back from vacation today but sadly I still won't be able to make the rescheduled initial meeting. By way of introduction, I took over from Joe Bergmark as the owner of CDI for WebSphere Application Server earlier this year and, assuming I manage to navigate the IBM process, will be looking to join the expert group. I am a relative newcomer to CDI having only returned to the JEE space in the past year after a break of 4-5 years. Prior to that, my expertise was in the areas of messaging, transactions and JCA. Regards, David From: Antoine Sabot-Durand To: cdi-dev Date: 29/08/2014 14:33 Subject: [cdi-dev] Spec launch meeting and CDI weekly meeting Sent by: cdi-dev-bounces at lists.jboss.org Hi All, On CDI 1.1, we use to have a weekly meeting each monday at 16:00 UTC (that?s 9:00 am PDT, 6:00 pm CEST and 9:30 pm IST). It?s hard to find a time slot that please everybody (from US West Coast to India), so Ir propose we keep this track. Now, if you have issue with this slot (if you live in New Zealand or Australia) say it and we?ll try to figure out a better slot (even if there?s no ideal one). The meeting place is the IRC channel and last one hour. We use an IRC bot (jbott) to keep track of meeting minutes for the record or people unable to attend the meeting. You can get familiarised with BOT commands here : https://wiki.debian.org/MeetBot So I propose we have our JSR launch meeting next monday (sept 1st) with the following agenda : - Discussion on the working method and tools used (mainly do we use Google Drive or Github with Asciidoc for working doc) - Discussion on each workshop I mentioned in my previous post and missing workshop * Workshop teams * Workflow chosen * estimated deadline (hard to say since we don?t know our workforce, but will be refined later) - Q & A if we still have time Note that It think we should avoid talking about specific content of workshop except if you think things are missing or that we could forgot them. If you want to see other points in the agenda let me know. I?m thrilled to start this great project with you guys. 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. 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/20140902/3e4b0a5a/attachment.html From werner.keil at gmail.com Wed Sep 3 12:03:46 2014 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 3 Sep 2014 18:03:46 +0200 Subject: [cdi-dev] cdi-dev Digest, Vol 46, Issue 1 In-Reply-To: References: Message-ID: Hi, Is the call taking place today? I seem to be the only one in the Hangout[?] IRC also gives troubles, the #cdi-dev room does not let me in for now. Is there any credential or user name you need to know to let us join? Thanks, Werner On Mon, Sep 1, 2014 at 3:24 PM, 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. Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - 19:00 (ASD > Perso) (Antoine Sabot-Durand) > 2. [JBoss JIRA] (CDI-45) Optional Injection Points > (Antoine Sabot-Durand (JIRA)) > 3. Re: Spec launch meeting and CDI weekly meeting (Filipe Portes) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 01 Sep 2014 09:47:52 +0000 > From: Antoine Sabot-Durand > Subject: [cdi-dev] Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - > 19:00 (ASD Perso) > To: "cdi-dev at lists.jboss.org" > Message-ID: <001a11c38b1c7c974f0501fde5be at google.com> > Content-Type: text/plain; charset="iso-8859-1" > > You have been invited to the following event. > > Title: CDI meeting > When: Wed 3 Sep 2014 18:00 - 19:00 Paris > Where: #cdi-dev on freenode IRC > Video call: https://plus.google.com/hangouts/_/sabot-durand.net/antoine > < > https://plus.google.com/hangouts/_/sabot-durand.net/antoine?hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0.jjn1b6jecn21kb68ap7a2162ok > > > Calendar: ASD Perso > Who: > * Antoine Sabot-Durand- organiser > * cdi-dev at lists.jboss.org > > Event details: > > https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I2OGFwN2EyMTYyb2sgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZmFhYWI3ZDMwMjU3NzlhOTM2MDIzMzExZWYwYmEwYmRlOWQ5ZjdlNg&ctz=Europe/Paris&hl=en_GB > > Invitation from Google Calendar: https://www.google.com/calendar/ > > You are receiving this courtesy email at the account > cdi-dev at lists.jboss.org because you are an attendee of this event. > > To stop receiving future notifications for this event, decline this event. > Alternatively, you can sign up for a Google account at > https://www.google.com/calendar/ and control your notification settings > for > your entire calendar. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0001.html > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: text/calendar > Size: 1074 bytes > Desc: not available > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0002.bin > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: invite.ics > Type: application/ics > Size: 1102 bytes > Desc: not available > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0003.bin > > ------------------------------ > > Message: 2 > Date: Mon, 1 Sep 2014 05:55:00 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Antoine Sabot-Durand updated CDI-45: > ------------------------------------ > Fix Version/s: 2.0 (discussion) > (was: TBD) > > > > Optional Injection Points > > ------------------------- > > > > Key: CDI-45 > > URL: https://issues.jboss.org/browse/CDI-45 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Resolution > > Affects Versions: 1.0 > > Reporter: Stuart Douglas > > Fix For: 2.0 (discussion) > > > > > > There are occoasions where it may be useful for some injection points to > be optional, e.g. > > @Inject > > @Optional > > MyBean bean; > > This would behave the same as a normal injection point, however it will > not cause the deployment to fail if it is not satisified. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.1#6329) > > > ------------------------------ > > Message: 3 > Date: Mon, 1 Sep 2014 10:24:37 -0300 > From: Filipe Portes > Subject: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting > To: Mark Paluch > Cc: cdi-dev > Message-ID: > Xhv_hngQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > here in brazil 16:00 UTC equals to 1:00 pm, so it's pretty good. > > > On Sat, Aug 30, 2014 at 9:00 AM, Mark Paluch wrote: > > > Either way is fine with me. In general 16:00 UTC is a good choice since > it > > seems not to be mid-might for anyone that is involved. > > > > Best regards, Mark > > > > Am 30.08.2014 um 12:53 schrieb Thorben Janssen : > > > > Wednesday at the same time is fine for me. > > Do you want to shift all meetings or only this one? > > > > Regards, > > Thorben > > ------------------------------ > > Von: Antoine Sabot-Durand > > Gesendet: ?30.?08.?2014 12:18 > > An: John D. Ament > > Cc: cdi-dev > > Betreff: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting > > > > Hi John, > > > > Sorry to have missed that. According to Pete, French are holidays > > specialists. I guess I have to improve my expertise in this domain ;). > > > > Is it ok for everybody to switch the meeting on Wednesday at the same > > time ? If there ware no objection I will send you an invitation Monday. > > > > > > > > Antoine > > > > Le 29 ao?t 2014 ? 18:53, John D. Ament a > ?crit : > > > > Could it be pushed to later in the week? Monday's a holiday in the US. > > > > > > On Fri, Aug 29, 2014 at 9:32 AM, Antoine Sabot-Durand < > > antoine at sabot-durand.net> wrote: > > > >> Hi All, > >> > >> On CDI 1.1, we use to have a weekly meeting each monday at 16:00 UTC > >> (that?s 9:00 am PDT, 6:00 pm CEST and 9:30 pm IST). It?s hard to find a > >> time slot that please everybody (from US West Coast to India), so Ir > >> propose we keep this track. Now, if you have issue with this slot (if > you > >> live in New Zealand or Australia) say it and we?ll try to figure out a > >> better slot (even if there?s no ideal one). > >> > >> The meeting place is the IRC channel and last one hour. We use an IRC > bot > >> (jbott) to keep track of meeting minutes for the record or people > unable to > >> attend the meeting. You can get familiarised with BOT commands here : > >> https://wiki.debian.org/MeetBot > >> > >> So I propose we have our JSR launch meeting next monday (sept 1st) with > >> the following agenda : > >> > >> - Discussion on the working method and tools used (mainly do we use > >> Google Drive or Github with Asciidoc for working doc) > >> - Discussion on each workshop I mentioned in my previous post and > missing > >> workshop > >> * Workshop teams > >> * Workflow chosen > >> * estimated deadline (hard to say since we don?t know our workforce, but > >> will be refined later) > >> - Q & A if we still have time > >> > >> Note that It think we should avoid talking about specific content of > >> workshop except if you think things are missing or that we could forgot > >> them. > >> If you want to see other points in the agenda let me know. > >> > >> I?m thrilled to start this great project with you guys. > >> > >> 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. > > > > > > > > _______________________________________________ > > 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. > > > > > > -- > Filipe Portes - @filipeportes > Senior Java EE/Web > JUGLeader Gojava - @gojava > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/attachment.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 46, Issue 1 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140903/9222c655/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 540 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140903/9222c655/attachment-0001.gif From mpaluch at paluch.biz Wed Sep 3 12:09:00 2014 From: mpaluch at paluch.biz (Mark Paluch) Date: Wed, 3 Sep 2014 18:09:00 +0200 Subject: [cdi-dev] cdi-dev Digest, Vol 46, Issue 1 In-Reply-To: References: Message-ID: <775F4479-78CD-4B7A-BDF0-873494FCCE74@paluch.biz> Hi Werner, the meeting is today (18:00 CEST) on #cdi-dev. You?ll have to register with freenode, I guess. No other special credentials needed. Best regards, Mark > Am 03.09.2014 um 18:03 schrieb Werner Keil : > > Hi, > > Is the call taking place today? > I seem to be the only one in the Hangout<35F.gif> > IRC also gives troubles, the #cdi-dev room does not let me in for now. Is there any credential or user name you need to know to let us join? > > Thanks, > Werner > > On Mon, Sep 1, 2014 at 3:24 PM, > 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. Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - 19:00 (ASD > Perso) (Antoine Sabot-Durand) > 2. [JBoss JIRA] (CDI-45) Optional Injection Points > (Antoine Sabot-Durand (JIRA)) > 3. Re: Spec launch meeting and CDI weekly meeting (Filipe Portes) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 01 Sep 2014 09:47:52 +0000 > From: Antoine Sabot-Durand > > Subject: [cdi-dev] Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - > 19:00 (ASD Perso) > To: "cdi-dev at lists.jboss.org " > > Message-ID: <001a11c38b1c7c974f0501fde5be at google.com > > Content-Type: text/plain; charset="iso-8859-1" > > You have been invited to the following event. > > Title: CDI meeting > When: Wed 3 Sep 2014 18:00 - 19:00 Paris > Where: #cdi-dev on freenode IRC > Video call: https://plus.google.com/hangouts/_/sabot-durand.net/antoine > > > Calendar: ASD Perso > Who: > * Antoine Sabot-Durand- organiser > * cdi-dev at lists.jboss.org > > Event details: > https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I2OGFwN2EyMTYyb2sgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZmFhYWI3ZDMwMjU3NzlhOTM2MDIzMzExZWYwYmEwYmRlOWQ5ZjdlNg&ctz=Europe/Paris&hl=en_GB > > Invitation from Google Calendar: https://www.google.com/calendar/ > > You are receiving this courtesy email at the account > cdi-dev at lists.jboss.org because you are an attendee of this event. > > To stop receiving future notifications for this event, decline this event. > Alternatively, you can sign up for a Google account at > https://www.google.com/calendar/ and control your notification settings for > your entire calendar. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0001.html > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: text/calendar > Size: 1074 bytes > Desc: not available > Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0002.bin > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: invite.ics > Type: application/ics > Size: 1102 bytes > Desc: not available > Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0003.bin > > ------------------------------ > > Message: 2 > Date: Mon, 1 Sep 2014 05:55:00 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > > Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Antoine Sabot-Durand updated CDI-45: > ------------------------------------ > Fix Version/s: 2.0 (discussion) > (was: TBD) > > > > Optional Injection Points > > ------------------------- > > > > Key: CDI-45 > > URL: https://issues.jboss.org/browse/CDI-45 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Resolution > > Affects Versions: 1.0 > > Reporter: Stuart Douglas > > Fix For: 2.0 (discussion) > > > > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > > @Inject > > @Optional > > MyBean bean; > > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.1#6329) > > > ------------------------------ > > Message: 3 > Date: Mon, 1 Sep 2014 10:24:37 -0300 > From: Filipe Portes > > Subject: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting > To: Mark Paluch > > Cc: cdi-dev > > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > here in brazil 16:00 UTC equals to 1:00 pm, so it's pretty good. > > > On Sat, Aug 30, 2014 at 9:00 AM, Mark Paluch > wrote: > > > Either way is fine with me. In general 16:00 UTC is a good choice since it > > seems not to be mid-might for anyone that is involved. > > > > Best regards, Mark > > > > Am 30.08.2014 um 12:53 schrieb Thorben Janssen >: > > > > Wednesday at the same time is fine for me. > > Do you want to shift all meetings or only this one? > > > > Regards, > > Thorben > > ------------------------------ > > Von: Antoine Sabot-Durand > > > Gesendet: ?30.?08.?2014 12:18 > > An: John D. Ament > > > Cc: cdi-dev > > > Betreff: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting > > > > Hi John, > > > > Sorry to have missed that. According to Pete, French are holidays > > specialists. I guess I have to improve my expertise in this domain ;). > > > > Is it ok for everybody to switch the meeting on Wednesday at the same > > time ? If there ware no objection I will send you an invitation Monday. > > > > > > > > Antoine > > > > Le 29 ao?t 2014 ? 18:53, John D. Ament > a ?crit : > > > > Could it be pushed to later in the week? Monday's a holiday in the US. > > > > > > On Fri, Aug 29, 2014 at 9:32 AM, Antoine Sabot-Durand < > > antoine at sabot-durand.net > wrote: > > > >> Hi All, > >> > >> On CDI 1.1, we use to have a weekly meeting each monday at 16:00 UTC > >> (that?s 9:00 am PDT, 6:00 pm CEST and 9:30 pm IST). It?s hard to find a > >> time slot that please everybody (from US West Coast to India), so Ir > >> propose we keep this track. Now, if you have issue with this slot (if you > >> live in New Zealand or Australia) say it and we?ll try to figure out a > >> better slot (even if there?s no ideal one). > >> > >> The meeting place is the IRC channel and last one hour. We use an IRC bot > >> (jbott) to keep track of meeting minutes for the record or people unable to > >> attend the meeting. You can get familiarised with BOT commands here : > >> https://wiki.debian.org/MeetBot > >> > >> So I propose we have our JSR launch meeting next monday (sept 1st) with > >> the following agenda : > >> > >> - Discussion on the working method and tools used (mainly do we use > >> Google Drive or Github with Asciidoc for working doc) > >> - Discussion on each workshop I mentioned in my previous post and missing > >> workshop > >> * Workshop teams > >> * Workflow chosen > >> * estimated deadline (hard to say since we don?t know our workforce, but > >> will be refined later) > >> - Q & A if we still have time > >> > >> Note that It think we should avoid talking about specific content of > >> workshop except if you think things are missing or that we could forgot > >> them. > >> If you want to see other points in the agenda let me know. > >> > >> I?m thrilled to start this great project with you guys. > >> > >> 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. > > > > > > > > _______________________________________________ > > 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. > > > > > > -- > Filipe Portes - @filipeportes > Senior Java EE/Web > JUGLeader Gojava > - @gojava > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/attachment.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 46, Issue 1 > ************************************** > > _______________________________________________ > 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/20140903/f229b1b4/attachment-0001.html From antonio.goncalves at gmail.com Wed Sep 3 12:14:27 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Wed, 3 Sep 2014 18:14:27 +0200 Subject: [cdi-dev] cdi-dev Digest, Vol 46, Issue 1 In-Reply-To: <775F4479-78CD-4B7A-BDF0-873494FCCE74@paluch.biz> References: <775F4479-78CD-4B7A-BDF0-873494FCCE74@paluch.biz> Message-ID: I just managed to log-on #cdi-dev, there was pb with the server I think On Wed, Sep 3, 2014 at 6:09 PM, Mark Paluch wrote: > Hi Werner, > the meeting is today (18:00 CEST) on #cdi-dev. > > You?ll have to register with freenode, I guess. No other special > credentials needed. > > Best regards, Mark > > Am 03.09.2014 um 18:03 schrieb Werner Keil : > > Hi, > > Is the call taking place today? > I seem to be the only one in the Hangout<35F.gif> > IRC also gives troubles, the #cdi-dev room does not let me in for now. Is > there any credential or user name you need to know to let us join? > > Thanks, > Werner > > On Mon, Sep 1, 2014 at 3:24 PM, 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. Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - 19:00 (ASD >> Perso) (Antoine Sabot-Durand) >> 2. [JBoss JIRA] (CDI-45) Optional Injection Points >> (Antoine Sabot-Durand (JIRA)) >> 3. Re: Spec launch meeting and CDI weekly meeting (Filipe Portes) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 01 Sep 2014 09:47:52 +0000 >> From: Antoine Sabot-Durand >> Subject: [cdi-dev] Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - >> 19:00 (ASD Perso) >> To: "cdi-dev at lists.jboss.org" >> Message-ID: <001a11c38b1c7c974f0501fde5be at google.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> You have been invited to the following event. >> >> Title: CDI meeting >> When: Wed 3 Sep 2014 18:00 - 19:00 Paris >> Where: #cdi-dev on freenode IRC >> Video call: https://plus.google.com/hangouts/_/sabot-durand.net/antoine >> < >> https://plus.google.com/hangouts/_/sabot-durand.net/antoine?hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0.jjn1b6jecn21kb68ap7a2162ok >> > >> Calendar: ASD Perso >> Who: >> * Antoine Sabot-Durand- organiser >> * cdi-dev at lists.jboss.org >> >> Event details: >> >> https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I2OGFwN2EyMTYyb2sgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZmFhYWI3ZDMwMjU3NzlhOTM2MDIzMzExZWYwYmEwYmRlOWQ5ZjdlNg&ctz=Europe/Paris&hl=en_GB >> >> Invitation from Google Calendar: https://www.google.com/calendar/ >> >> You are receiving this courtesy email at the account >> cdi-dev at lists.jboss.org because you are an attendee of this event. >> >> To stop receiving future notifications for this event, decline this event. >> Alternatively, you can sign up for a Google account at >> https://www.google.com/calendar/ and control your notification settings >> for >> your entire calendar. >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0001.html >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: not available >> Type: text/calendar >> Size: 1074 bytes >> Desc: not available >> Url : >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0002.bin >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: invite.ics >> Type: application/ics >> Size: 1102 bytes >> Desc: not available >> Url : >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0003.bin >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 1 Sep 2014 05:55:00 -0400 (EDT) >> From: "Antoine Sabot-Durand (JIRA)" >> Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points >> To: cdi-dev at lists.jboss.org >> Message-ID: >> >> Content-Type: text/plain; charset=UTF-8 >> >> >> [ >> https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> Antoine Sabot-Durand updated CDI-45: >> ------------------------------------ >> Fix Version/s: 2.0 (discussion) >> (was: TBD) >> >> >> > Optional Injection Points >> > ------------------------- >> > >> > Key: CDI-45 >> > URL: https://issues.jboss.org/browse/CDI-45 >> > Project: CDI Specification Issues >> > Issue Type: Feature Request >> > Components: Resolution >> > Affects Versions: 1.0 >> > Reporter: Stuart Douglas >> > Fix For: 2.0 (discussion) >> > >> > >> > There are occoasions where it may be useful for some injection points >> to be optional, e.g. >> > @Inject >> > @Optional >> > MyBean bean; >> > This would behave the same as a normal injection point, however it will >> not cause the deployment to fail if it is not satisified. >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.3.1#6329) >> >> >> ------------------------------ >> >> Message: 3 >> Date: Mon, 1 Sep 2014 10:24:37 -0300 >> From: Filipe Portes >> Subject: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting >> To: Mark Paluch >> Cc: cdi-dev >> Message-ID: >> > Xhv_hngQ at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> here in brazil 16:00 UTC equals to 1:00 pm, so it's pretty good. >> >> >> On Sat, Aug 30, 2014 at 9:00 AM, Mark Paluch wrote: >> >> > Either way is fine with me. In general 16:00 UTC is a good choice since >> it >> > seems not to be mid-might for anyone that is involved. >> > >> > Best regards, Mark >> > >> > Am 30.08.2014 um 12:53 schrieb Thorben Janssen > >: >> > >> > Wednesday at the same time is fine for me. >> > Do you want to shift all meetings or only this one? >> > >> > Regards, >> > Thorben >> > ------------------------------ >> > Von: Antoine Sabot-Durand >> > Gesendet: ?30.?08.?2014 12:18 >> > An: John D. Ament >> > Cc: cdi-dev >> > Betreff: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting >> > >> > Hi John, >> > >> > Sorry to have missed that. According to Pete, French are holidays >> > specialists. I guess I have to improve my expertise in this domain ;). >> > >> > Is it ok for everybody to switch the meeting on Wednesday at the same >> > time ? If there ware no objection I will send you an invitation Monday. >> > >> > >> > >> > Antoine >> > >> > Le 29 ao?t 2014 ? 18:53, John D. Ament a >> ?crit : >> > >> > Could it be pushed to later in the week? Monday's a holiday in the US. >> > >> > >> > On Fri, Aug 29, 2014 at 9:32 AM, Antoine Sabot-Durand < >> > antoine at sabot-durand.net> wrote: >> > >> >> Hi All, >> >> >> >> On CDI 1.1, we use to have a weekly meeting each monday at 16:00 UTC >> >> (that?s 9:00 am PDT, 6:00 pm CEST and 9:30 pm IST). It?s hard to find >> a >> >> time slot that please everybody (from US West Coast to India), so Ir >> >> propose we keep this track. Now, if you have issue with this slot (if >> you >> >> live in New Zealand or Australia) say it and we?ll try to figure out a >> >> better slot (even if there?s no ideal one). >> >> >> >> The meeting place is the IRC channel and last one hour. We use an IRC >> bot >> >> (jbott) to keep track of meeting minutes for the record or people >> unable to >> >> attend the meeting. You can get familiarised with BOT commands here : >> >> https://wiki.debian.org/MeetBot >> >> >> >> So I propose we have our JSR launch meeting next monday (sept 1st) with >> >> the following agenda : >> >> >> >> - Discussion on the working method and tools used (mainly do we use >> >> Google Drive or Github with Asciidoc for working doc) >> >> - Discussion on each workshop I mentioned in my previous post and >> missing >> >> workshop >> >> * Workshop teams >> >> * Workflow chosen >> >> * estimated deadline (hard to say since we don?t know our workforce, >> but >> >> will be refined later) >> >> - Q & A if we still have time >> >> >> >> Note that It think we should avoid talking about specific content of >> >> workshop except if you think things are missing or that we could forgot >> >> them. >> >> If you want to see other points in the agenda let me know. >> >> >> >> I?m thrilled to start this great project with you guys. >> >> >> >> 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. >> > >> > >> > >> > _______________________________________________ >> > 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. >> > >> >> >> >> -- >> Filipe Portes - @filipeportes >> Senior Java EE/Web >> JUGLeader Gojava - @gojava >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/attachment.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 46, Issue 1 >> ************************************** >> > > _______________________________________________ > 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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140903/4ef372f0/attachment-0001.html From werner.keil at gmail.com Wed Sep 3 12:15:47 2014 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 3 Sep 2014 18:15:47 +0200 Subject: [cdi-dev] cdi-dev Digest, Vol 46, Issue 6 In-Reply-To: References: Message-ID: I am registered with Freenode, that also recognizes my alias, but trying to enter #cdi-dev fails with an error: #cdi-dev Cannot join channel (+r) - you need to be identified with services Any idea how to fix this? Thanks, Werner 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. Re: cdi-dev Digest, Vol 46, Issue 1 (Mark Paluch) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 3 Sep 2014 18:09:00 +0200 > From: Mark Paluch > Subject: Re: [cdi-dev] cdi-dev Digest, Vol 46, Issue 1 > To: Werner Keil > Cc: cdi-dev > Message-ID: <775F4479-78CD-4B7A-BDF0-873494FCCE74 at paluch.biz> > Content-Type: text/plain; charset="utf-8" > > Hi Werner, > the meeting is today (18:00 CEST) on #cdi-dev. > > You?ll have to register with freenode, I guess. No other special > credentials needed. > > Best regards, Mark > > > Am 03.09.2014 um 18:03 schrieb Werner Keil : > > > > Hi, > > > > Is the call taking place today? > > I seem to be the only one in the Hangout<35F.gif> > > IRC also gives troubles, the #cdi-dev room does not let me in for now. > Is there any credential or user name you need to know to let us join? > > > > Thanks, > > Werner > > > > On Mon, Sep 1, 2014 at 3:24 PM, > 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 < > 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 cdi-dev-request at lists.jboss.org> > > > > You can reach the person managing the list at > > cdi-dev-owner at lists.jboss.org 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. Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - 19:00 (ASD > > Perso) (Antoine Sabot-Durand) > > 2. [JBoss JIRA] (CDI-45) Optional Injection Points > > (Antoine Sabot-Durand (JIRA)) > > 3. Re: Spec launch meeting and CDI weekly meeting (Filipe Portes) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 01 Sep 2014 09:47:52 +0000 > > From: Antoine Sabot-Durand antoine at sabot-durand.net>> > > Subject: [cdi-dev] Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - > > 19:00 (ASD Perso) > > To: "cdi-dev at lists.jboss.org " < > cdi-dev at lists.jboss.org > > > Message-ID: <001a11c38b1c7c974f0501fde5be at google.com 001a11c38b1c7c974f0501fde5be at google.com>> > > Content-Type: text/plain; charset="iso-8859-1" > > > > You have been invited to the following event. > > > > Title: CDI meeting > > When: Wed 3 Sep 2014 18:00 - 19:00 Paris > > Where: #cdi-dev on freenode IRC > > Video call: https://plus.google.com/hangouts/_/sabot-durand.net/antoine > > > < > https://plus.google.com/hangouts/_/sabot-durand.net/antoine?hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0.jjn1b6jecn21kb68ap7a2162ok > < > https://plus.google.com/hangouts/_/sabot-durand.net/antoine?hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0.jjn1b6jecn21kb68ap7a2162ok > >> > > Calendar: ASD Perso > > Who: > > * Antoine Sabot-Durand- organiser > > * cdi-dev at lists.jboss.org > > > > Event details: > > > https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I2OGFwN2EyMTYyb2sgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZmFhYWI3ZDMwMjU3NzlhOTM2MDIzMzExZWYwYmEwYmRlOWQ5ZjdlNg&ctz=Europe/Paris&hl=en_GB > < > https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I2OGFwN2EyMTYyb2sgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZmFhYWI3ZDMwMjU3NzlhOTM2MDIzMzExZWYwYmEwYmRlOWQ5ZjdlNg&ctz=Europe/Paris&hl=en_GB > > > > > > Invitation from Google Calendar: https://www.google.com/calendar/ < > https://www.google.com/calendar/> > > > > You are receiving this courtesy email at the account > > cdi-dev at lists.jboss.org because you > are an attendee of this event. > > > > To stop receiving future notifications for this event, decline this > event. > > Alternatively, you can sign up for a Google account at > > https://www.google.com/calendar/ and > control your notification settings for > > your entire calendar. > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0001.html > < > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0001.html > > > > -------------- next part -------------- > > A non-text attachment was scrubbed... > > Name: not available > > Type: text/calendar > > Size: 1074 bytes > > Desc: not available > > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0002.bin > < > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0002.bin > > > > -------------- next part -------------- > > A non-text attachment was scrubbed... > > Name: invite.ics > > Type: application/ics > > Size: 1102 bytes > > Desc: not available > > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0003.bin > < > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0003.bin > > > > > > ------------------------------ > > > > Message: 2 > > Date: Mon, 1 Sep 2014 05:55:00 -0400 (EDT) > > From: "Antoine Sabot-Durand (JIRA)" issues at jboss.org>> > > Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points > > To: cdi-dev at lists.jboss.org > > Message-ID: > > > > Content-Type: text/plain; charset=UTF-8 > > > > > > [ > https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > < > https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel> > ] > > > > Antoine Sabot-Durand updated CDI-45: > > ------------------------------------ > > Fix Version/s: 2.0 (discussion) > > (was: TBD) > > > > > > > Optional Injection Points > > > ------------------------- > > > > > > Key: CDI-45 > > > URL: https://issues.jboss.org/browse/CDI-45 < > https://issues.jboss.org/browse/CDI-45> > > > Project: CDI Specification Issues > > > Issue Type: Feature Request > > > Components: Resolution > > > Affects Versions: 1.0 > > > Reporter: Stuart Douglas > > > Fix For: 2.0 (discussion) > > > > > > > > > There are occoasions where it may be useful for some injection points > to be optional, e.g. > > > @Inject > > > @Optional > > > MyBean bean; > > > This would behave the same as a normal injection point, however it > will not cause the deployment to fail if it is not satisified. > > > > > > > > -- > > This message was sent by Atlassian JIRA > > (v6.3.1#6329) > > > > > > ------------------------------ > > > > Message: 3 > > Date: Mon, 1 Sep 2014 10:24:37 -0300 > > From: Filipe Portes >> > > Subject: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting > > To: Mark Paluch > > > Cc: cdi-dev > > > Message-ID: > > Xhv_hngQ at mail.gmail.com > > > Content-Type: text/plain; charset="utf-8" > > > > here in brazil 16:00 UTC equals to 1:00 pm, so it's pretty good. > > > > > > On Sat, Aug 30, 2014 at 9:00 AM, Mark Paluch > wrote: > > > > > Either way is fine with me. In general 16:00 UTC is a good choice > since it > > > seems not to be mid-might for anyone that is involved. > > > > > > Best regards, Mark > > > > > > Am 30.08.2014 um 12:53 schrieb Thorben Janssen >: > > > > > > Wednesday at the same time is fine for me. > > > Do you want to shift all meetings or only this one? > > > > > > Regards, > > > Thorben > > > ------------------------------ > > > Von: Antoine Sabot-Durand antoine at sabot-durand.net>> > > > Gesendet: ?30.?08.?2014 12:18 > > > An: John D. Ament john.d.ament at gmail.com>> > > > Cc: cdi-dev > > > > Betreff: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting > > > > > > Hi John, > > > > > > Sorry to have missed that. According to Pete, French are holidays > > > specialists. I guess I have to improve my expertise in this domain ;). > > > > > > Is it ok for everybody to switch the meeting on Wednesday at the same > > > time ? If there ware no objection I will send you an invitation Monday. > > > > > > > > > > > > Antoine > > > > > > Le 29 ao?t 2014 ? 18:53, John D. Ament > a ?crit : > > > > > > Could it be pushed to later in the week? Monday's a holiday in the US. > > > > > > > > > On Fri, Aug 29, 2014 at 9:32 AM, Antoine Sabot-Durand < > > > antoine at sabot-durand.net > wrote: > > > > > >> Hi All, > > >> > > >> On CDI 1.1, we use to have a weekly meeting each monday at 16:00 UTC > > >> (that?s 9:00 am PDT, 6:00 pm CEST and 9:30 pm IST). It?s hard to > find a > > >> time slot that please everybody (from US West Coast to India), so Ir > > >> propose we keep this track. Now, if you have issue with this slot (if > you > > >> live in New Zealand or Australia) say it and we?ll try to figure out a > > >> better slot (even if there?s no ideal one). > > >> > > >> The meeting place is the IRC channel and last one hour. We use an IRC > bot > > >> (jbott) to keep track of meeting minutes for the record or people > unable to > > >> attend the meeting. You can get familiarised with BOT commands here : > > >> https://wiki.debian.org/MeetBot > > >> > > >> So I propose we have our JSR launch meeting next monday (sept 1st) > with > > >> the following agenda : > > >> > > >> - Discussion on the working method and tools used (mainly do we use > > >> Google Drive or Github with Asciidoc for working doc) > > >> - Discussion on each workshop I mentioned in my previous post and > missing > > >> workshop > > >> * Workshop teams > > >> * Workflow chosen > > >> * estimated deadline (hard to say since we don?t know our workforce, > but > > >> will be refined later) > > >> - Q & A if we still have time > > >> > > >> Note that It think we should avoid talking about specific content of > > >> workshop except if you think things are missing or that we could > forgot > > >> them. > > >> If you want to see other points in the agenda let me know. > > >> > > >> I?m thrilled to start this great project with you guys. > > >> > > >> Antoine > > >> > > >> _______________________________________________ > > >> cdi-dev mailing list > > >> cdi-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/cdi-dev < > 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 < > 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 < > 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 < > 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 < > 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 < > 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. > > > > > > > > > > > -- > > Filipe Portes - @filipeportes > > Senior Java EE/Web > > JUGLeader Gojava > - > @gojava > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/attachment.html > < > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/attachment.html > > > > > > ------------------------------ > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev < > 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 < > 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 46, Issue 1 > > ************************************** > > > > _______________________________________________ > > 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/20140903/f229b1b4/attachment.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 46, Issue 6 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140903/0b137e6f/attachment-0001.html From omeuefilipe at gmail.com Wed Sep 3 12:17:38 2014 From: omeuefilipe at gmail.com (Filipe Portes) Date: Wed, 3 Sep 2014 13:17:38 -0300 Subject: [cdi-dev] cdi-dev Digest, Vol 46, Issue 6 In-Reply-To: References: Message-ID: you need to join #NIckServ and run this command: /msg NickServ IDENTIFY yourusername yourpassword On Wed, Sep 3, 2014 at 1:15 PM, Werner Keil wrote: > I am registered with Freenode, that also recognizes my alias, but trying > to enter #cdi-dev fails with an error: > #cdi-dev Cannot join channel (+r) - you need to be identified with > services > > > Any idea how to fix this? > > Thanks, > Werner > > 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. Re: cdi-dev Digest, Vol 46, Issue 1 (Mark Paluch) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 3 Sep 2014 18:09:00 +0200 >> From: Mark Paluch >> Subject: Re: [cdi-dev] cdi-dev Digest, Vol 46, Issue 1 >> To: Werner Keil >> Cc: cdi-dev >> Message-ID: <775F4479-78CD-4B7A-BDF0-873494FCCE74 at paluch.biz> >> Content-Type: text/plain; charset="utf-8" >> >> Hi Werner, >> the meeting is today (18:00 CEST) on #cdi-dev. >> >> You?ll have to register with freenode, I guess. No other special >> credentials needed. >> >> Best regards, Mark >> >> > Am 03.09.2014 um 18:03 schrieb Werner Keil : >> > >> > Hi, >> > >> > Is the call taking place today? >> > I seem to be the only one in the Hangout<35F.gif> >> > IRC also gives troubles, the #cdi-dev room does not let me in for now. >> Is there any credential or user name you need to know to let us join? >> > >> > Thanks, >> > Werner >> > >> > On Mon, Sep 1, 2014 at 3:24 PM, > > 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 < >> 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 > cdi-dev-request at lists.jboss.org> >> > >> > You can reach the person managing the list at >> > cdi-dev-owner at lists.jboss.org > 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. Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - 19:00 (ASD >> > Perso) (Antoine Sabot-Durand) >> > 2. [JBoss JIRA] (CDI-45) Optional Injection Points >> > (Antoine Sabot-Durand (JIRA)) >> > 3. Re: Spec launch meeting and CDI weekly meeting (Filipe Portes) >> > >> > >> > ---------------------------------------------------------------------- >> > >> > Message: 1 >> > Date: Mon, 01 Sep 2014 09:47:52 +0000 >> > From: Antoine Sabot-Durand > antoine at sabot-durand.net>> >> > Subject: [cdi-dev] Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - >> > 19:00 (ASD Perso) >> > To: "cdi-dev at lists.jboss.org " < >> cdi-dev at lists.jboss.org > >> > Message-ID: <001a11c38b1c7c974f0501fde5be at google.com > 001a11c38b1c7c974f0501fde5be at google.com>> >> > Content-Type: text/plain; charset="iso-8859-1" >> > >> > You have been invited to the following event. >> > >> > Title: CDI meeting >> > When: Wed 3 Sep 2014 18:00 - 19:00 Paris >> > Where: #cdi-dev on freenode IRC >> > Video call: https://plus.google.com/hangouts/_/sabot-durand.net/antoine >> >> > < >> https://plus.google.com/hangouts/_/sabot-durand.net/antoine?hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0.jjn1b6jecn21kb68ap7a2162ok >> < >> https://plus.google.com/hangouts/_/sabot-durand.net/antoine?hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0.jjn1b6jecn21kb68ap7a2162ok >> >> >> > Calendar: ASD Perso >> > Who: >> > * Antoine Sabot-Durand- organiser >> > * cdi-dev at lists.jboss.org >> > >> > Event details: >> > >> https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I2OGFwN2EyMTYyb2sgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZmFhYWI3ZDMwMjU3NzlhOTM2MDIzMzExZWYwYmEwYmRlOWQ5ZjdlNg&ctz=Europe/Paris&hl=en_GB >> < >> https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I2OGFwN2EyMTYyb2sgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZmFhYWI3ZDMwMjU3NzlhOTM2MDIzMzExZWYwYmEwYmRlOWQ5ZjdlNg&ctz=Europe/Paris&hl=en_GB >> > >> > >> > Invitation from Google Calendar: https://www.google.com/calendar/ < >> https://www.google.com/calendar/> >> > >> > You are receiving this courtesy email at the account >> > cdi-dev at lists.jboss.org because you >> are an attendee of this event. >> > >> > To stop receiving future notifications for this event, decline this >> event. >> > Alternatively, you can sign up for a Google account at >> > https://www.google.com/calendar/ >> and control your notification settings for >> > your entire calendar. >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0001.html >> < >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0001.html >> > >> > -------------- next part -------------- >> > A non-text attachment was scrubbed... >> > Name: not available >> > Type: text/calendar >> > Size: 1074 bytes >> > Desc: not available >> > Url : >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0002.bin >> < >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0002.bin >> > >> > -------------- next part -------------- >> > A non-text attachment was scrubbed... >> > Name: invite.ics >> > Type: application/ics >> > Size: 1102 bytes >> > Desc: not available >> > Url : >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0003.bin >> < >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0003.bin >> > >> > >> > ------------------------------ >> > >> > Message: 2 >> > Date: Mon, 1 Sep 2014 05:55:00 -0400 (EDT) >> > From: "Antoine Sabot-Durand (JIRA)" > issues at jboss.org>> >> > Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points >> > To: cdi-dev at lists.jboss.org >> > Message-ID: >> > > > >> > Content-Type: text/plain; charset=UTF-8 >> > >> > >> > [ >> https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> < >> https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel> >> ] >> > >> > Antoine Sabot-Durand updated CDI-45: >> > ------------------------------------ >> > Fix Version/s: 2.0 (discussion) >> > (was: TBD) >> > >> > >> > > Optional Injection Points >> > > ------------------------- >> > > >> > > Key: CDI-45 >> > > URL: https://issues.jboss.org/browse/CDI-45 < >> https://issues.jboss.org/browse/CDI-45> >> > > Project: CDI Specification Issues >> > > Issue Type: Feature Request >> > > Components: Resolution >> > > Affects Versions: 1.0 >> > > Reporter: Stuart Douglas >> > > Fix For: 2.0 (discussion) >> > > >> > > >> > > There are occoasions where it may be useful for some injection points >> to be optional, e.g. >> > > @Inject >> > > @Optional >> > > MyBean bean; >> > > This would behave the same as a normal injection point, however it >> will not cause the deployment to fail if it is not satisified. >> > >> > >> > >> > -- >> > This message was sent by Atlassian JIRA >> > (v6.3.1#6329) >> > >> > >> > ------------------------------ >> > >> > Message: 3 >> > Date: Mon, 1 Sep 2014 10:24:37 -0300 >> > From: Filipe Portes > omeuefilipe at gmail.com>> >> > Subject: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting >> > To: Mark Paluch > >> > Cc: cdi-dev > >> > Message-ID: >> > > Xhv_hngQ at mail.gmail.com > >> > Content-Type: text/plain; charset="utf-8" >> > >> > here in brazil 16:00 UTC equals to 1:00 pm, so it's pretty good. >> > >> > >> > On Sat, Aug 30, 2014 at 9:00 AM, Mark Paluch > > wrote: >> > >> > > Either way is fine with me. In general 16:00 UTC is a good choice >> since it >> > > seems not to be mid-might for anyone that is involved. >> > > >> > > Best regards, Mark >> > > >> > > Am 30.08.2014 um 12:53 schrieb Thorben Janssen < >> thjanssen123 at gmail.com >: >> > > >> > > Wednesday at the same time is fine for me. >> > > Do you want to shift all meetings or only this one? >> > > >> > > Regards, >> > > Thorben >> > > ------------------------------ >> > > Von: Antoine Sabot-Durand > antoine at sabot-durand.net>> >> > > Gesendet: ?30.?08.?2014 12:18 >> > > An: John D. Ament > john.d.ament at gmail.com>> >> > > Cc: cdi-dev > >> >> > > Betreff: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting >> > > >> > > Hi John, >> > > >> > > Sorry to have missed that. According to Pete, French are holidays >> > > specialists. I guess I have to improve my expertise in this domain ;). >> > > >> > > Is it ok for everybody to switch the meeting on Wednesday at the same >> > > time ? If there ware no objection I will send you an invitation >> Monday. >> > > >> > > >> > > >> > > Antoine >> > > >> > > Le 29 ao?t 2014 ? 18:53, John D. Ament > > a ?crit : >> > > >> > > Could it be pushed to later in the week? Monday's a holiday in the >> US. >> > > >> > > >> > > On Fri, Aug 29, 2014 at 9:32 AM, Antoine Sabot-Durand < >> > > antoine at sabot-durand.net > wrote: >> > > >> > >> Hi All, >> > >> >> > >> On CDI 1.1, we use to have a weekly meeting each monday at 16:00 UTC >> > >> (that?s 9:00 am PDT, 6:00 pm CEST and 9:30 pm IST). It?s hard to >> find a >> > >> time slot that please everybody (from US West Coast to India), so Ir >> > >> propose we keep this track. Now, if you have issue with this slot >> (if you >> > >> live in New Zealand or Australia) say it and we?ll try to figure out >> a >> > >> better slot (even if there?s no ideal one). >> > >> >> > >> The meeting place is the IRC channel and last one hour. We use an >> IRC bot >> > >> (jbott) to keep track of meeting minutes for the record or people >> unable to >> > >> attend the meeting. You can get familiarised with BOT commands here : >> > >> https://wiki.debian.org/MeetBot >> > >> >> > >> So I propose we have our JSR launch meeting next monday (sept 1st) >> with >> > >> the following agenda : >> > >> >> > >> - Discussion on the working method and tools used (mainly do we use >> > >> Google Drive or Github with Asciidoc for working doc) >> > >> - Discussion on each workshop I mentioned in my previous post and >> missing >> > >> workshop >> > >> * Workshop teams >> > >> * Workflow chosen >> > >> * estimated deadline (hard to say since we don?t know our workforce, >> but >> > >> will be refined later) >> > >> - Q & A if we still have time >> > >> >> > >> Note that It think we should avoid talking about specific content of >> > >> workshop except if you think things are missing or that we could >> forgot >> > >> them. >> > >> If you want to see other points in the agenda let me know. >> > >> >> > >> I?m thrilled to start this great project with you guys. >> > >> >> > >> Antoine >> > >> >> > >> _______________________________________________ >> > >> cdi-dev mailing list >> > >> cdi-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev < >> 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 < >> 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 < >> 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 < >> 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 < >> 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 < >> 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. >> > > >> > >> > >> > >> > -- >> > Filipe Portes - @filipeportes >> > Senior Java EE/Web >> > JUGLeader Gojava > - >> @gojava >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/attachment.html >> < >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/attachment.html >> > >> > >> > ------------------------------ >> > >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev < >> 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 < >> 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 46, Issue 1 >> > ************************************** >> > >> > _______________________________________________ >> > 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/20140903/f229b1b4/attachment.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 46, Issue 6 >> ************************************** >> > > > _______________________________________________ > 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. > -- Filipe Portes - @filipeportes Senior Java EE/Web JUGLeader Gojava - @gojava -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140903/4a570601/attachment-0001.html From radhakrishnan.mohan at gmail.com Wed Sep 3 12:29:05 2014 From: radhakrishnan.mohan at gmail.com (Mohan Radhakrishnan) Date: Wed, 3 Sep 2014 21:59:05 +0530 Subject: [cdi-dev] cdi-dev Digest, Vol 46, Issue 6 In-Reply-To: References: Message-ID: I did this. /msg NickServ identify But can't see other users. On Wed, Sep 3, 2014 at 9:45 PM, Werner Keil wrote: > I am registered with Freenode, that also recognizes my alias, but trying > to enter #cdi-dev fails with an error: > #cdi-dev Cannot join channel (+r) - you need to be identified with > services > > > Any idea how to fix this? > > Thanks, > Werner > > 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. Re: cdi-dev Digest, Vol 46, Issue 1 (Mark Paluch) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 3 Sep 2014 18:09:00 +0200 >> From: Mark Paluch >> Subject: Re: [cdi-dev] cdi-dev Digest, Vol 46, Issue 1 >> To: Werner Keil >> Cc: cdi-dev >> Message-ID: <775F4479-78CD-4B7A-BDF0-873494FCCE74 at paluch.biz> >> Content-Type: text/plain; charset="utf-8" >> >> Hi Werner, >> the meeting is today (18:00 CEST) on #cdi-dev. >> >> You?ll have to register with freenode, I guess. No other special >> credentials needed. >> >> Best regards, Mark >> >> > Am 03.09.2014 um 18:03 schrieb Werner Keil : >> > >> > Hi, >> > >> > Is the call taking place today? >> > I seem to be the only one in the Hangout<35F.gif> >> > IRC also gives troubles, the #cdi-dev room does not let me in for now. >> Is there any credential or user name you need to know to let us join? >> > >> > Thanks, >> > Werner >> > >> > On Mon, Sep 1, 2014 at 3:24 PM, > > 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 < >> 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 > cdi-dev-request at lists.jboss.org> >> > >> > You can reach the person managing the list at >> > cdi-dev-owner at lists.jboss.org > 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. Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - 19:00 (ASD >> > Perso) (Antoine Sabot-Durand) >> > 2. [JBoss JIRA] (CDI-45) Optional Injection Points >> > (Antoine Sabot-Durand (JIRA)) >> > 3. Re: Spec launch meeting and CDI weekly meeting (Filipe Portes) >> > >> > >> > ---------------------------------------------------------------------- >> > >> > Message: 1 >> > Date: Mon, 01 Sep 2014 09:47:52 +0000 >> > From: Antoine Sabot-Durand > antoine at sabot-durand.net>> >> > Subject: [cdi-dev] Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - >> > 19:00 (ASD Perso) >> > To: "cdi-dev at lists.jboss.org " < >> cdi-dev at lists.jboss.org > >> > Message-ID: <001a11c38b1c7c974f0501fde5be at google.com > 001a11c38b1c7c974f0501fde5be at google.com>> >> > Content-Type: text/plain; charset="iso-8859-1" >> > >> > You have been invited to the following event. >> > >> > Title: CDI meeting >> > When: Wed 3 Sep 2014 18:00 - 19:00 Paris >> > Where: #cdi-dev on freenode IRC >> > Video call: https://plus.google.com/hangouts/_/sabot-durand.net/antoine >> >> > < >> https://plus.google.com/hangouts/_/sabot-durand.net/antoine?hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0.jjn1b6jecn21kb68ap7a2162ok >> < >> https://plus.google.com/hangouts/_/sabot-durand.net/antoine?hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0.jjn1b6jecn21kb68ap7a2162ok >> >> >> > Calendar: ASD Perso >> > Who: >> > * Antoine Sabot-Durand- organiser >> > * cdi-dev at lists.jboss.org >> > >> > Event details: >> > >> https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I2OGFwN2EyMTYyb2sgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZmFhYWI3ZDMwMjU3NzlhOTM2MDIzMzExZWYwYmEwYmRlOWQ5ZjdlNg&ctz=Europe/Paris&hl=en_GB >> < >> https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I2OGFwN2EyMTYyb2sgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZmFhYWI3ZDMwMjU3NzlhOTM2MDIzMzExZWYwYmEwYmRlOWQ5ZjdlNg&ctz=Europe/Paris&hl=en_GB >> > >> > >> > Invitation from Google Calendar: https://www.google.com/calendar/ < >> https://www.google.com/calendar/> >> > >> > You are receiving this courtesy email at the account >> > cdi-dev at lists.jboss.org because you >> are an attendee of this event. >> > >> > To stop receiving future notifications for this event, decline this >> event. >> > Alternatively, you can sign up for a Google account at >> > https://www.google.com/calendar/ >> and control your notification settings for >> > your entire calendar. >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0001.html >> < >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0001.html >> > >> > -------------- next part -------------- >> > A non-text attachment was scrubbed... >> > Name: not available >> > Type: text/calendar >> > Size: 1074 bytes >> > Desc: not available >> > Url : >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0002.bin >> < >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0002.bin >> > >> > -------------- next part -------------- >> > A non-text attachment was scrubbed... >> > Name: invite.ics >> > Type: application/ics >> > Size: 1102 bytes >> > Desc: not available >> > Url : >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0003.bin >> < >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0003.bin >> > >> > >> > ------------------------------ >> > >> > Message: 2 >> > Date: Mon, 1 Sep 2014 05:55:00 -0400 (EDT) >> > From: "Antoine Sabot-Durand (JIRA)" > issues at jboss.org>> >> > Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points >> > To: cdi-dev at lists.jboss.org >> > Message-ID: >> > > > >> > Content-Type: text/plain; charset=UTF-8 >> > >> > >> > [ >> https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> < >> https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel> >> ] >> > >> > Antoine Sabot-Durand updated CDI-45: >> > ------------------------------------ >> > Fix Version/s: 2.0 (discussion) >> > (was: TBD) >> > >> > >> > > Optional Injection Points >> > > ------------------------- >> > > >> > > Key: CDI-45 >> > > URL: https://issues.jboss.org/browse/CDI-45 < >> https://issues.jboss.org/browse/CDI-45> >> > > Project: CDI Specification Issues >> > > Issue Type: Feature Request >> > > Components: Resolution >> > > Affects Versions: 1.0 >> > > Reporter: Stuart Douglas >> > > Fix For: 2.0 (discussion) >> > > >> > > >> > > There are occoasions where it may be useful for some injection points >> to be optional, e.g. >> > > @Inject >> > > @Optional >> > > MyBean bean; >> > > This would behave the same as a normal injection point, however it >> will not cause the deployment to fail if it is not satisified. >> > >> > >> > >> > -- >> > This message was sent by Atlassian JIRA >> > (v6.3.1#6329) >> > >> > >> > ------------------------------ >> > >> > Message: 3 >> > Date: Mon, 1 Sep 2014 10:24:37 -0300 >> > From: Filipe Portes > omeuefilipe at gmail.com>> >> > Subject: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting >> > To: Mark Paluch > >> > Cc: cdi-dev > >> > Message-ID: >> > > Xhv_hngQ at mail.gmail.com > >> > Content-Type: text/plain; charset="utf-8" >> > >> > here in brazil 16:00 UTC equals to 1:00 pm, so it's pretty good. >> > >> > >> > On Sat, Aug 30, 2014 at 9:00 AM, Mark Paluch > > wrote: >> > >> > > Either way is fine with me. In general 16:00 UTC is a good choice >> since it >> > > seems not to be mid-might for anyone that is involved. >> > > >> > > Best regards, Mark >> > > >> > > Am 30.08.2014 um 12:53 schrieb Thorben Janssen < >> thjanssen123 at gmail.com >: >> > > >> > > Wednesday at the same time is fine for me. >> > > Do you want to shift all meetings or only this one? >> > > >> > > Regards, >> > > Thorben >> > > ------------------------------ >> > > Von: Antoine Sabot-Durand > antoine at sabot-durand.net>> >> > > Gesendet: ?30.?08.?2014 12:18 >> > > An: John D. Ament > john.d.ament at gmail.com>> >> > > Cc: cdi-dev > >> >> > > Betreff: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting >> > > >> > > Hi John, >> > > >> > > Sorry to have missed that. According to Pete, French are holidays >> > > specialists. I guess I have to improve my expertise in this domain ;). >> > > >> > > Is it ok for everybody to switch the meeting on Wednesday at the same >> > > time ? If there ware no objection I will send you an invitation >> Monday. >> > > >> > > >> > > >> > > Antoine >> > > >> > > Le 29 ao?t 2014 ? 18:53, John D. Ament > > a ?crit : >> > > >> > > Could it be pushed to later in the week? Monday's a holiday in the >> US. >> > > >> > > >> > > On Fri, Aug 29, 2014 at 9:32 AM, Antoine Sabot-Durand < >> > > antoine at sabot-durand.net > wrote: >> > > >> > >> Hi All, >> > >> >> > >> On CDI 1.1, we use to have a weekly meeting each monday at 16:00 UTC >> > >> (that?s 9:00 am PDT, 6:00 pm CEST and 9:30 pm IST). It?s hard to >> find a >> > >> time slot that please everybody (from US West Coast to India), so Ir >> > >> propose we keep this track. Now, if you have issue with this slot >> (if you >> > >> live in New Zealand or Australia) say it and we?ll try to figure out >> a >> > >> better slot (even if there?s no ideal one). >> > >> >> > >> The meeting place is the IRC channel and last one hour. We use an >> IRC bot >> > >> (jbott) to keep track of meeting minutes for the record or people >> unable to >> > >> attend the meeting. You can get familiarised with BOT commands here : >> > >> https://wiki.debian.org/MeetBot >> > >> >> > >> So I propose we have our JSR launch meeting next monday (sept 1st) >> with >> > >> the following agenda : >> > >> >> > >> - Discussion on the working method and tools used (mainly do we use >> > >> Google Drive or Github with Asciidoc for working doc) >> > >> - Discussion on each workshop I mentioned in my previous post and >> missing >> > >> workshop >> > >> * Workshop teams >> > >> * Workflow chosen >> > >> * estimated deadline (hard to say since we don?t know our workforce, >> but >> > >> will be refined later) >> > >> - Q & A if we still have time >> > >> >> > >> Note that It think we should avoid talking about specific content of >> > >> workshop except if you think things are missing or that we could >> forgot >> > >> them. >> > >> If you want to see other points in the agenda let me know. >> > >> >> > >> I?m thrilled to start this great project with you guys. >> > >> >> > >> Antoine >> > >> >> > >> _______________________________________________ >> > >> cdi-dev mailing list >> > >> cdi-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev < >> 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 < >> 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 < >> 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 < >> 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 < >> 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 < >> 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. >> > > >> > >> > >> > >> > -- >> > Filipe Portes - @filipeportes >> > Senior Java EE/Web >> > JUGLeader Gojava > - >> @gojava >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/attachment.html >> < >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/attachment.html >> > >> > >> > ------------------------------ >> > >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev < >> 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 < >> 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 46, Issue 1 >> > ************************************** >> > >> > _______________________________________________ >> > 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/20140903/f229b1b4/attachment.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 46, Issue 6 >> ************************************** >> > > > _______________________________________________ > 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/20140903/00154d71/attachment-0001.html From radhakrishnan.mohan at gmail.com Wed Sep 3 12:36:04 2014 From: radhakrishnan.mohan at gmail.com (Mohan Radhakrishnan) Date: Wed, 3 Sep 2014 22:06:04 +0530 Subject: [cdi-dev] cdi-dev Digest, Vol 46, Issue 6 In-Reply-To: References: Message-ID: After that I Changed channel using /j #cdi-dev successfully. On Wed, Sep 3, 2014 at 9:59 PM, Mohan Radhakrishnan < radhakrishnan.mohan at gmail.com> wrote: > I did this. > > /msg NickServ identify > > But can't see other users. > > > On Wed, Sep 3, 2014 at 9:45 PM, Werner Keil wrote: > >> I am registered with Freenode, that also recognizes my alias, but trying >> to enter #cdi-dev fails with an error: >> #cdi-dev Cannot join channel (+r) - you need to be identified with >> services >> >> >> Any idea how to fix this? >> >> Thanks, >> Werner >> >> 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. Re: cdi-dev Digest, Vol 46, Issue 1 (Mark Paluch) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Wed, 3 Sep 2014 18:09:00 +0200 >>> From: Mark Paluch >>> Subject: Re: [cdi-dev] cdi-dev Digest, Vol 46, Issue 1 >>> To: Werner Keil >>> Cc: cdi-dev >>> Message-ID: <775F4479-78CD-4B7A-BDF0-873494FCCE74 at paluch.biz> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hi Werner, >>> the meeting is today (18:00 CEST) on #cdi-dev. >>> >>> You?ll have to register with freenode, I guess. No other special >>> credentials needed. >>> >>> Best regards, Mark >>> >>> > Am 03.09.2014 um 18:03 schrieb Werner Keil : >>> > >>> > Hi, >>> > >>> > Is the call taking place today? >>> > I seem to be the only one in the Hangout<35F.gif> >>> > IRC also gives troubles, the #cdi-dev room does not let me in for now. >>> Is there any credential or user name you need to know to let us join? >>> > >>> > Thanks, >>> > Werner >>> > >>> > On Mon, Sep 1, 2014 at 3:24 PM, >> > 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 < >>> 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 >> cdi-dev-request at lists.jboss.org> >>> > >>> > You can reach the person managing the list at >>> > cdi-dev-owner at lists.jboss.org >> 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. Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - 19:00 (ASD >>> > Perso) (Antoine Sabot-Durand) >>> > 2. [JBoss JIRA] (CDI-45) Optional Injection Points >>> > (Antoine Sabot-Durand (JIRA)) >>> > 3. Re: Spec launch meeting and CDI weekly meeting (Filipe Portes) >>> > >>> > >>> > ---------------------------------------------------------------------- >>> > >>> > Message: 1 >>> > Date: Mon, 01 Sep 2014 09:47:52 +0000 >>> > From: Antoine Sabot-Durand >> antoine at sabot-durand.net>> >>> > Subject: [cdi-dev] Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - >>> > 19:00 (ASD Perso) >>> > To: "cdi-dev at lists.jboss.org " < >>> cdi-dev at lists.jboss.org > >>> > Message-ID: <001a11c38b1c7c974f0501fde5be at google.com >> 001a11c38b1c7c974f0501fde5be at google.com>> >>> > Content-Type: text/plain; charset="iso-8859-1" >>> > >>> > You have been invited to the following event. >>> > >>> > Title: CDI meeting >>> > When: Wed 3 Sep 2014 18:00 - 19:00 Paris >>> > Where: #cdi-dev on freenode IRC >>> > Video call: >>> https://plus.google.com/hangouts/_/sabot-durand.net/antoine < >>> https://plus.google.com/hangouts/_/sabot-durand.net/antoine> >>> > < >>> https://plus.google.com/hangouts/_/sabot-durand.net/antoine?hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0.jjn1b6jecn21kb68ap7a2162ok >>> < >>> https://plus.google.com/hangouts/_/sabot-durand.net/antoine?hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0.jjn1b6jecn21kb68ap7a2162ok >>> >> >>> > Calendar: ASD Perso >>> > Who: >>> > * Antoine Sabot-Durand- organiser >>> > * cdi-dev at lists.jboss.org >>> > >>> > Event details: >>> > >>> https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I2OGFwN2EyMTYyb2sgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZmFhYWI3ZDMwMjU3NzlhOTM2MDIzMzExZWYwYmEwYmRlOWQ5ZjdlNg&ctz=Europe/Paris&hl=en_GB >>> < >>> https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I2OGFwN2EyMTYyb2sgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZmFhYWI3ZDMwMjU3NzlhOTM2MDIzMzExZWYwYmEwYmRlOWQ5ZjdlNg&ctz=Europe/Paris&hl=en_GB >>> > >>> > >>> > Invitation from Google Calendar: https://www.google.com/calendar/ < >>> https://www.google.com/calendar/> >>> > >>> > You are receiving this courtesy email at the account >>> > cdi-dev at lists.jboss.org because you >>> are an attendee of this event. >>> > >>> > To stop receiving future notifications for this event, decline this >>> event. >>> > Alternatively, you can sign up for a Google account at >>> > https://www.google.com/calendar/ >>> and control your notification settings for >>> > your entire calendar. >>> > -------------- next part -------------- >>> > An HTML attachment was scrubbed... >>> > URL: >>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0001.html >>> < >>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0001.html >>> > >>> > -------------- next part -------------- >>> > A non-text attachment was scrubbed... >>> > Name: not available >>> > Type: text/calendar >>> > Size: 1074 bytes >>> > Desc: not available >>> > Url : >>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0002.bin >>> < >>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0002.bin >>> > >>> > -------------- next part -------------- >>> > A non-text attachment was scrubbed... >>> > Name: invite.ics >>> > Type: application/ics >>> > Size: 1102 bytes >>> > Desc: not available >>> > Url : >>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0003.bin >>> < >>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/attachment-0003.bin >>> > >>> > >>> > ------------------------------ >>> > >>> > Message: 2 >>> > Date: Mon, 1 Sep 2014 05:55:00 -0400 (EDT) >>> > From: "Antoine Sabot-Durand (JIRA)" >> issues at jboss.org>> >>> > Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points >>> > To: cdi-dev at lists.jboss.org >>> > Message-ID: >>> > >> > >>> > Content-Type: text/plain; charset=UTF-8 >>> > >>> > >>> > [ >>> https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >>> < >>> https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel> >>> ] >>> > >>> > Antoine Sabot-Durand updated CDI-45: >>> > ------------------------------------ >>> > Fix Version/s: 2.0 (discussion) >>> > (was: TBD) >>> > >>> > >>> > > Optional Injection Points >>> > > ------------------------- >>> > > >>> > > Key: CDI-45 >>> > > URL: https://issues.jboss.org/browse/CDI-45 < >>> https://issues.jboss.org/browse/CDI-45> >>> > > Project: CDI Specification Issues >>> > > Issue Type: Feature Request >>> > > Components: Resolution >>> > > Affects Versions: 1.0 >>> > > Reporter: Stuart Douglas >>> > > Fix For: 2.0 (discussion) >>> > > >>> > > >>> > > There are occoasions where it may be useful for some injection >>> points to be optional, e.g. >>> > > @Inject >>> > > @Optional >>> > > MyBean bean; >>> > > This would behave the same as a normal injection point, however it >>> will not cause the deployment to fail if it is not satisified. >>> > >>> > >>> > >>> > -- >>> > This message was sent by Atlassian JIRA >>> > (v6.3.1#6329) >>> > >>> > >>> > ------------------------------ >>> > >>> > Message: 3 >>> > Date: Mon, 1 Sep 2014 10:24:37 -0300 >>> > From: Filipe Portes >> omeuefilipe at gmail.com>> >>> > Subject: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting >>> > To: Mark Paluch > >>> > Cc: cdi-dev > >>> > Message-ID: >>> > >> Xhv_hngQ at mail.gmail.com > >>> > Content-Type: text/plain; charset="utf-8" >>> > >>> > here in brazil 16:00 UTC equals to 1:00 pm, so it's pretty good. >>> > >>> > >>> > On Sat, Aug 30, 2014 at 9:00 AM, Mark Paluch >> > wrote: >>> > >>> > > Either way is fine with me. In general 16:00 UTC is a good choice >>> since it >>> > > seems not to be mid-might for anyone that is involved. >>> > > >>> > > Best regards, Mark >>> > > >>> > > Am 30.08.2014 um 12:53 schrieb Thorben Janssen < >>> thjanssen123 at gmail.com >: >>> > > >>> > > Wednesday at the same time is fine for me. >>> > > Do you want to shift all meetings or only this one? >>> > > >>> > > Regards, >>> > > Thorben >>> > > ------------------------------ >>> > > Von: Antoine Sabot-Durand >> antoine at sabot-durand.net>> >>> > > Gesendet: ?30.?08.?2014 12:18 >>> > > An: John D. Ament >> john.d.ament at gmail.com>> >>> > > Cc: cdi-dev >> >> >>> > > Betreff: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting >>> > > >>> > > Hi John, >>> > > >>> > > Sorry to have missed that. According to Pete, French are holidays >>> > > specialists. I guess I have to improve my expertise in this domain >>> ;). >>> > > >>> > > Is it ok for everybody to switch the meeting on Wednesday at the >>> same >>> > > time ? If there ware no objection I will send you an invitation >>> Monday. >>> > > >>> > > >>> > > >>> > > Antoine >>> > > >>> > > Le 29 ao?t 2014 ? 18:53, John D. Ament >> > a ?crit : >>> > > >>> > > Could it be pushed to later in the week? Monday's a holiday in the >>> US. >>> > > >>> > > >>> > > On Fri, Aug 29, 2014 at 9:32 AM, Antoine Sabot-Durand < >>> > > antoine at sabot-durand.net > wrote: >>> > > >>> > >> Hi All, >>> > >> >>> > >> On CDI 1.1, we use to have a weekly meeting each monday at 16:00 UTC >>> > >> (that?s 9:00 am PDT, 6:00 pm CEST and 9:30 pm IST). It?s hard to >>> find a >>> > >> time slot that please everybody (from US West Coast to India), so Ir >>> > >> propose we keep this track. Now, if you have issue with this slot >>> (if you >>> > >> live in New Zealand or Australia) say it and we?ll try to figure >>> out a >>> > >> better slot (even if there?s no ideal one). >>> > >> >>> > >> The meeting place is the IRC channel and last one hour. We use an >>> IRC bot >>> > >> (jbott) to keep track of meeting minutes for the record or people >>> unable to >>> > >> attend the meeting. You can get familiarised with BOT commands here >>> : >>> > >> https://wiki.debian.org/MeetBot >>> > >> >>> > >> So I propose we have our JSR launch meeting next monday (sept 1st) >>> with >>> > >> the following agenda : >>> > >> >>> > >> - Discussion on the working method and tools used (mainly do we use >>> > >> Google Drive or Github with Asciidoc for working doc) >>> > >> - Discussion on each workshop I mentioned in my previous post and >>> missing >>> > >> workshop >>> > >> * Workshop teams >>> > >> * Workflow chosen >>> > >> * estimated deadline (hard to say since we don?t know our >>> workforce, but >>> > >> will be refined later) >>> > >> - Q & A if we still have time >>> > >> >>> > >> Note that It think we should avoid talking about specific content of >>> > >> workshop except if you think things are missing or that we could >>> forgot >>> > >> them. >>> > >> If you want to see other points in the agenda let me know. >>> > >> >>> > >> I?m thrilled to start this great project with you guys. >>> > >> >>> > >> Antoine >>> > >> >>> > >> _______________________________________________ >>> > >> cdi-dev mailing list >>> > >> cdi-dev at lists.jboss.org >>> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev < >>> 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 < >>> 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 < >>> 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 < >>> 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 < >>> 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 < >>> 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. >>> > > >>> > >>> > >>> > >>> > -- >>> > Filipe Portes - @filipeportes >>> > Senior Java EE/Web >>> > JUGLeader Gojava > - >>> @gojava >>> > -------------- next part -------------- >>> > An HTML attachment was scrubbed... >>> > URL: >>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/attachment.html >>> < >>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/attachment.html >>> > >>> > >>> > ------------------------------ >>> > >>> > _______________________________________________ >>> > cdi-dev mailing list >>> > cdi-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/cdi-dev < >>> 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 < >>> 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 46, Issue 1 >>> > ************************************** >>> > >>> > _______________________________________________ >>> > 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/20140903/f229b1b4/attachment.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 46, Issue 6 >>> ************************************** >>> >> >> >> _______________________________________________ >> 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/20140903/effd3cd6/attachment-0001.html From issues at jboss.org Thu Sep 4 02:37:59 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 4 Sep 2014 02:37:59 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: Mark Struberg created CDI-456: --------------------------------- Summary: fix Bean#getBeanClass() definition Key: CDI-456 URL: https://issues.jboss.org/browse/CDI-456 Project: CDI Specification Issues Issue Type: Bug Components: Beans Reporter: Mark Struberg currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. Imo this only causes troubles and doesn't add any benefit. * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. * At the time we create interceptors we ONLY need the type which is to be created; * At the time we create the normalscoping proxies we ONLY need the type which is to be created; In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 04:38:59 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 4 Sep 2014 04:38:59 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998713#comment-12998713 ] Jozef Hartinger commented on CDI-456: ------------------------------------- The reason why getBeanClass() is defined as it is is modularity. In CDI the concept of "bean class" is used to determine whether a bean in module A is visible to a different bean in module B or not. For producer methods and fields it is the declaring class that determines this, not the return type. If you for example have an EAR with multiple wars and one of them defines Foo.class: {code:JAVA} public class Foo { @Produces String foo() { return "foo"; } } {code} You want to use Foo.class (the declaring class) to determine visibility of the producer method, not String.class (the return type) as otherwise your producer would be visible from all the other WARs! This is especially the case for custom beans where you have no knowledge if the custom bean represents a producer field/method or not. See section 5.1. Modularity for details. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 05:19:59 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 4 Sep 2014 05:19:59 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998748#comment-12998748 ] Mark Struberg commented on CDI-456: ----------------------------------- But Jozef, this is broken for all manually added Beans. E.g. consider you add a Bean in just one single WebApp. Detecting the module by by only using getBeanClass() just doesn't work. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 05:24:00 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 4 Sep 2014 05:24:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998749#comment-12998749 ] Jozef Hartinger commented on CDI-456: ------------------------------------- Why not? And why should we restrict this to single WebApp and ignore multi-module scenarios? > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 08:08:00 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 4 Sep 2014 08:08:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998837#comment-12998837 ] Mark Struberg commented on CDI-456: ----------------------------------- Sorry, seems my explanation was too brief ;) Imagine you have an EAR with 3 WARs. Each of the WAR files add a Bean with the same class (which is in a shared ear lib), but with different bean attributes and different content. The beanclass would be the same for all the 3 Bean, but they are still in 3 totally different EE modules. What means getBeanClass() is not usable to distinct the EE modules. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 08:37:03 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 4 Sep 2014 08:37:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998852#comment-12998852 ] Jozef Hartinger commented on CDI-456: ------------------------------------- Why would you return the same bean class in all the three cases? If each WAR bundled a class with a producer method each producing this shared type (let's call it S), these producers would not have S as their bean class for exactly this reason ;-) > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 08:41:01 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 4 Sep 2014 08:41:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998857#comment-12998857 ] Romain Manni-Bucau commented on CDI-456: ---------------------------------------- Class is not enough to know from which module you are so it is not usable (OSGi or EE). I tend to be agree with Mark, beanClass can be the producer class but there is no custom producer in CDI - a "custom producer" is a custom Bean so it knows which type to return. So +1 to force bean class to return the instance type for custom Beans > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 08:43:01 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 4 Sep 2014 08:43:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998859#comment-12998859 ] Martin Kouba commented on CDI-456: ---------------------------------- [~struberg] What do you mean "WAR files add a Bean with the same class"? By means of a portable extension? > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 08:44:02 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 4 Sep 2014 08:44:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998860#comment-12998860 ] Jozef Hartinger commented on CDI-456: ------------------------------------- {quote}Class is not enough to know from which module you are so it is not usable (OSGi or EE).{quote} Why not? And if not how otherwise should the CDI impl know which module the custom Bean belongs to? > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 08:53:01 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 4 Sep 2014 08:53:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998868#comment-12998868 ] Romain Manni-Bucau commented on CDI-456: ---------------------------------------- Classloading isolation can be restricted but it doesn't mean you don't inherit from other beans (typically in OSGi you can get proxies to solve it). In EE that's the same, nothing prevents it if you *custom* beans handle it correctly. In EE that's worse since the deployment is pretty clear (=hierarchic) so no need to test Class to know what should be done. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 09:27:02 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 4 Sep 2014 09:27:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998896#comment-12998896 ] Jozef Hartinger commented on CDI-456: ------------------------------------- Can you elaborate more on how a CDI implementation should know which module a custom Bean belongs to? I am not able to understand that from your reply. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 09:31:02 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 4 Sep 2014 09:31:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998899#comment-12998899 ] Romain Manni-Bucau commented on CDI-456: ---------------------------------------- Well in a war no big deal, in an ear the container does it since it deploys it. If you 100% want to do it from the CDI container "alone" you just can't. Then you are right you can use bean class but it doesn't cover 100% of cases (most of them for sure). It doesn't change the main point: getBeanClass is not designed for it IMHO, no? You think it is here for modules? > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 09:39:01 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 4 Sep 2014 09:39:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998910#comment-12998910 ] Jozef Hartinger commented on CDI-456: ------------------------------------- {quote}You think it is here for modules?{quote} Not only for modules but yes. It referenced quite a lot in Section 5.1. Modularity {quote}Well in a war no big deal{quote} How? {quote} in an ear the container does it since it deploys it{quote} How? You have an extension that registered a custom bean. What information do you use to infer where the bean belongs? The same module as the extension's? Some type from Bean.getTypes()? Or something else? > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 09:40:00 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 4 Sep 2014 09:40:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998910#comment-12998910 ] Jozef Hartinger edited comment on CDI-456 at 9/4/14 9:39 AM: ------------------------------------------------------------- {quote}You think it is here for modules?{quote} Not only for modules but yes. It's referenced quite a lot in Section 5.1. Modularity {quote}Well in a war no big deal{quote} How? {quote} in an ear the container does it since it deploys it{quote} How? You have an extension that registered a custom bean. What information do you use to infer where the bean belongs? The same module as the extension's? Some type from Bean.getTypes()? Or something else? was (Author: jharting): {quote}You think it is here for modules?{quote} Not only for modules but yes. It referenced quite a lot in Section 5.1. Modularity {quote}Well in a war no big deal{quote} How? {quote} in an ear the container does it since it deploys it{quote} How? You have an extension that registered a custom bean. What information do you use to infer where the bean belongs? The same module as the extension's? Some type from Bean.getTypes()? Or something else? > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 10:00:06 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 4 Sep 2014 10:00:06 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998923#comment-12998923 ] Romain Manni-Bucau commented on CDI-456: ---------------------------------------- for wars it is mainly a 'flat' classloader so all beans are "shared" so nothing fancy to do? for extension yes but honestly not sure that's that important. If you use beanclass and that the bean class is not in the app (in upper classloaders) then what do you do? > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 10:06:00 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 4 Sep 2014 10:06:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998925#comment-12998925 ] Jozef Hartinger commented on CDI-456: ------------------------------------- {quote} If you use beanclass and that the bean class is not in the app (in upper classloaders) then what do you do?{quote} That's a different question. If the bean class *is* in the app though then getBeanClass() can tell us whether this bean belongs to war1, war2, war3, shared library or somewhere else which is pretty important information. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 10:24:02 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 4 Sep 2014 10:24:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998942#comment-12998942 ] Romain Manni-Bucau commented on CDI-456: ---------------------------------------- well my point is you can't rely on it generally so its usage shouldn't be this one. Maybe it just means we should have getProxiableType() and getLocation in Bean2 (next version) wdyt? > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 10:32:04 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 4 Sep 2014 10:32:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998952#comment-12998952 ] Jozef Hartinger commented on CDI-456: ------------------------------------- You can rely on that always. No matter where bean1 and bean2 are packaged you know that bean1 can be injected into bean2 as long as bean2.getBeanClass() can see bean1.getBeanClass(). I agree with you that this is by no means ideal and there are better ways to express this e.g. your getLocation() method. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 10:42:00 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 4 Sep 2014 10:42:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998956#comment-12998956 ] Romain Manni-Bucau commented on CDI-456: ---------------------------------------- so you bean testing the classloader always? this is broken in OSGi where you often use proxy in create() but not in getBeanClass to allow this to work > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 10:42:01 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 4 Sep 2014 10:42:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998956#comment-12998956 ] Romain Manni-Bucau edited comment on CDI-456 at 9/4/14 10:41 AM: ----------------------------------------------------------------- so you mean by testing the classloader from one class to the other? this is broken in OSGi where you often use proxy in create() but not in getBeanClass to allow this to work was (Author: rmannibucau): so you bean testing the classloader always? this is broken in OSGi where you often use proxy in create() but not in getBeanClass to allow this to work > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 12:43:01 2014 From: issues at jboss.org (Mark Paluch (JIRA)) Date: Thu, 4 Sep 2014 12:43:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999065#comment-12999065 ] Mark Paluch commented on CDI-456: --------------------------------- The CDI container would do that. The container would not provide the bean if it's not visible to another module. In the end this means {{Bean#getBeanClass()}} is the class of the providing bean (either the class itself or the producer class). Introducing a {{Bean.getProxiableType()}} that consistently returns the type which gets created could be a possible solution to inspect the type of the resulting object. Other DI frameworks name it for example {{getObjectType()}}. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 12:50:00 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 4 Sep 2014 12:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999067#comment-12999067 ] Romain Manni-Bucau commented on CDI-456: ---------------------------------------- more I think to it more I see an issue. If the goal is module visibility resolution then we should add a Bean#isVisible(Module) - with Module providing at least the ClassLoader, maybe a name from beans.xml like in ejb-jar.xml, the location?... Using beanClass and classloader is not portable at all and even if EE containers can surely deal with it, in SE and OSGi worlds it will be very fragile. I think this can be an interesting topic to complete scanning config which was recently introduced. This will be close to OSGi import/export control then. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 12:58:59 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 4 Sep 2014 12:58:59 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Add a disposable interface In-Reply-To: References: Message-ID: John Ament created CDI-457: ------------------------------ Summary: Add a disposable interface Key: CDI-457 URL: https://issues.jboss.org/browse/CDI-457 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Reporter: John Ament Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed. I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 13:46:59 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 4 Sep 2014 13:46:59 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Add a disposable interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament reassigned CDI-457: ------------------------------ Assignee: John Ament > Add a disposable interface > -------------------------- > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed. > I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 16:01:02 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 4 Sep 2014 16:01:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999120#comment-12999120 ] Mark Struberg commented on CDI-456: ----------------------------------- [~mkouba] yes, 3 Extensions - 1 in each of the WARs - add 3 different Bean which produce the same Class, but different content. The container must not use the class to detect in which part of the application the Bean is valid and in which not. There must be other mechanisms. Each of the WARs could use a different Extension instance for example and store the created/parsed/whatever Beans in a different location. THAT would be modular. But just using a Class which can be used in tons of different Beans is not. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 03:25:02 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Fri, 5 Sep 2014 03:25:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999198#comment-12999198 ] Jozef Hartinger commented on CDI-456: ------------------------------------- {quote}Using beanClass and classloader is not portable at all and even if EE containers can surely deal with it, in SE and OSGi worlds it will be very fragile.{quote} No matter what environment you are running, if you have class A and class B in Java you can always tell if A's ClassLoader can see B or not. No matter if it's OSGi, an EE container that does or does not isolate modules, a plain flat SE classpath or something completely different, you can always determine this. What CDI should do is to behave the same and make A injectable to B as long as A is visible from B or in other words if you can do new A() within B. That is the only sane way to define accesibility in CDI - to follow ClassLoader accesibility. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 03:29:00 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Fri, 5 Sep 2014 03:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999201#comment-12999201 ] Jozef Hartinger commented on CDI-456: ------------------------------------- {quote}But just using a Class which can be used in tons of different Beans is not.{quote} Exactly. If bean type and bean class are the same thing (as this ticket proposes) accesibility resolution won't work well. That's why it is important for producers and often custom beans to distinguish between the type of the bean and the class that defines it! > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 03:29:01 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 5 Sep 2014 03:29:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Add a disposable interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999202#comment-12999202 ] Martin Kouba commented on CDI-457: ---------------------------------- Please be more specific. By default, a dependent bean is bound to the lifecycle of the object it's injected into - in this case, it's needed as long as the object is. For producers, initializers and producers we have {{@TransientReference}}. There is also {{Instance.destroy()}} method. Etc. ... > Add a disposable interface > -------------------------- > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed. > I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 04:02:01 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 5 Sep 2014 04:02:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999205#comment-12999205 ] Mark Struberg commented on CDI-456: ----------------------------------- [~jharting] you still get me wrong. There are situations where the type of the class is not enough to determine the module. It does work for producer methods which are NOT modified/created via Extensions, but that's all. And for those (producers are ONLY internal beans) the container has MUCH better ways to detect the module. Which means it is absolutely useless and just makes it impossible to properly do things like e.g. ProcessProducer etc.... > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 04:12:01 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Fri, 5 Sep 2014 04:12:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999207#comment-12999207 ] Jozef Hartinger commented on CDI-456: ------------------------------------- {quote}There are situations where the type of the class is not enough to determine the module.{quote} As long as you use the right class as the bean class, which often is not the bean type, this works for producers and custom beans. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 04:12:59 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 5 Sep 2014 04:12:59 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-458: ---------------------------------------- Summary: Give the possibility to deactivate an observer in ProcessObserverMethod Key: CDI-458 URL: https://issues.jboss.org/browse/CDI-458 Project: CDI Specification Issues Issue Type: Feature Request Components: Events, Portable Extensions Affects Versions: 1.2.Final Reporter: Antoine Sabot-Durand Today if a user want to deactivate an observer at deployment time, she needs to observes {{ProcessAnnotatedType}} with {{@WithAnnotation(Observes.class)}} and replace the annotatedType by a new one without the {{@Observes}} annotation. It's quite heavy to manage. We could add a {{veto()}} method in {{ProcessObserverMethod}} to do this in a far easier and intuitive way. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 04:12:59 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 5 Sep 2014 04:12:59 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-458: ------------------------------------- Fix Version/s: 2.0 (discussion) > Give the possibility to deactivate an observer in ProcessObserverMethod > ----------------------------------------------------------------------- > > Key: CDI-458 > URL: https://issues.jboss.org/browse/CDI-458 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > Today if a user want to deactivate an observer at deployment time, she needs to observes {{ProcessAnnotatedType}} with {{@WithAnnotation(Observes.class)}} and replace the annotatedType by a new one without the {{@Observes}} annotation. It's quite heavy to manage. > We could add a {{veto()}} method in {{ProcessObserverMethod}} to do this in a far easier and intuitive way. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 04:42:04 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 5 Sep 2014 04:42:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999219#comment-12999219 ] Mark Struberg commented on CDI-456: ----------------------------------- Jozef NO IT DOES NOT! beanclass -> Bean is NOT 1:1 if you register different Bean in each of the 3 WAR files. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antoine at sabot-durand.net Fri Sep 5 05:36:12 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 5 Sep 2014 11:36:12 +0200 Subject: [cdi-dev] Collaboration between @Inject 2.0 and CDI 2.0 Message-ID: <812F5D40-BA5D-463A-91F4-A014E2284B6E@sabot-durand.net> Bob, Juergen, The work on CDI 2.0 is starting this week. As we said before we would really like to collaborate with you on a true DI java standard. I understand you?re both quite busy right now, but as we need to have some ideas of coming features in the new @Inject specification we?re proposing to do the first move. So we?re planning to write a document providing feature we?d like to have in this new specification. We hope this doc will be a good helper to start discussion around the spec. Again you?re welcome on the CDI EG or if don?t feel like going official with JCP on our Mailing List : https://lists.jboss.org/mailman/listinfo/cdi-dev Thanks for your time Antoine Sabot-Durand ??????????????? Twitter : @antoine_sd CDI co-spec lead & eco-system development Agorava tech lead -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/ccef3fda/attachment.html From antoine at sabot-durand.net Fri Sep 5 06:22:26 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 5 Sep 2014 12:22:26 +0200 Subject: [cdi-dev] Tools : Google Drive vs Asciidoc and Github Message-ID: Hi all, To pursue the discussion we had during last meeting, I really think we should use both tools for the workshop. that?s how I see things : In early stage in the workshop the working doc is changing fast and could probably content ideas that will disappear in future version (impossible or breaking backward compatibility). This phase needs fast collaboration between people knowing that the doc content is volatile and more in ?brain storm? than in ?part of the final spec? mode. For these reason I think we should set this working phase in Google Drive. It will be easier to collaborate synchronously on the doc and separate the very early draft to more advance phase. When an agreement (we have to define that yet) will be reached on this doc, it will be converted in Asciidoc (the plugin works nicely) and integrated to the spec website. The change will course continue but if we didn?t missed big mistake there will be less of them and they could be done thru PR. WDYT ? Antoine From pmuir at redhat.com Fri Sep 5 06:47:28 2014 From: pmuir at redhat.com (Pete Muir) Date: Fri, 5 Sep 2014 11:47:28 +0100 Subject: [cdi-dev] Tools : Google Drive vs Asciidoc and Github In-Reply-To: References: Message-ID: <60C02ADD-24B9-4EC7-9EFB-C5A64345BB03@redhat.com> I agree. Asciidoc is not a good tool for quick collaboration. On 5 Sep 2014, at 11:22, Antoine Sabot-Durand wrote: > Hi all, > > > To pursue the discussion we had during last meeting, I really think we should use both tools for the workshop. that?s how I see things : > > In early stage in the workshop the working doc is changing fast and could probably content ideas that will disappear in future version (impossible or breaking backward compatibility). > This phase needs fast collaboration between people knowing that the doc content is volatile and more in ?brain storm? than in ?part of the final spec? mode. For these reason I think we should set this working phase in Google Drive. It will be easier to collaborate synchronously on the doc and separate the very early draft to more advance phase. > > When an agreement (we have to define that yet) will be reached on this doc, it will be converted in Asciidoc (the plugin works nicely) and integrated to the spec website. The change will course continue but if we didn?t missed big mistake there will be less of them and they could be done thru PR. > > WDYT ? > > 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 mpaluch at paluch.biz Fri Sep 5 08:10:38 2014 From: mpaluch at paluch.biz (Mark Paluch) Date: Fri, 5 Sep 2014 14:10:38 +0200 Subject: [cdi-dev] Tools : Google Drive vs Asciidoc and Github In-Reply-To: <60C02ADD-24B9-4EC7-9EFB-C5A64345BB03@redhat.com> References: <60C02ADD-24B9-4EC7-9EFB-C5A64345BB03@redhat.com> Message-ID: <8C2B6A9A-63C9-4143-8E4E-03587F294F3C@paluch.biz> I have the same opinion on that. Additionally, the Google Drive stuff won?t confuse CDI spec visitors on GitHub with ideas that are not settled yet. +1 from me. Am 05.09.2014 um 12:47 schrieb Pete Muir : > I agree. Asciidoc is not a good tool for quick collaboration. > > On 5 Sep 2014, at 11:22, Antoine Sabot-Durand wrote: > >> Hi all, >> >> >> To pursue the discussion we had during last meeting, I really think we should use both tools for the workshop. that?s how I see things : >> >> In early stage in the workshop the working doc is changing fast and could probably content ideas that will disappear in future version (impossible or breaking backward compatibility). >> This phase needs fast collaboration between people knowing that the doc content is volatile and more in ?brain storm? than in ?part of the final spec? mode. For these reason I think we should set this working phase in Google Drive. It will be easier to collaborate synchronously on the doc and separate the very early draft to more advance phase. >> >> When an agreement (we have to define that yet) will be reached on this doc, it will be converted in Asciidoc (the plugin works nicely) and integrated to the spec website. The change will course continue but if we didn?t missed big mistake there will be less of them and they could be done thru PR. >> >> WDYT ? >> >> 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 antonio.goncalves at gmail.com Fri Sep 5 09:02:31 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Fri, 5 Sep 2014 15:02:31 +0200 Subject: [cdi-dev] Tools : Google Drive vs Asciidoc and Github In-Reply-To: References: Message-ID: +1 On Fri, Sep 5, 2014 at 12:22 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > > To pursue the discussion we had during last meeting, I really think we > should use both tools for the workshop. that?s how I see things : > > In early stage in the workshop the working doc is changing fast and could > probably content ideas that will disappear in future version (impossible or > breaking backward compatibility). > This phase needs fast collaboration between people knowing that the doc > content is volatile and more in ?brain storm? than in ?part of the final > spec? mode. For these reason I think we should set this working phase in > Google Drive. It will be easier to collaborate synchronously on the doc and > separate the very early draft to more advance phase. > > When an agreement (we have to define that yet) will be reached on this > doc, it will be converted in Asciidoc (the plugin works nicely) and > integrated to the spec website. The change will course continue but if we > didn?t missed big mistake there will be less of them and they could be done > thru PR. > > WDYT ? > > 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. -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/44e50d00/attachment.html From antoine at sabot-durand.net Fri Sep 5 09:28:05 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 5 Sep 2014 15:28:05 +0200 Subject: [cdi-dev] With the end of Java Config... Message-ID: <20184D0D-5AE3-4FF8-B2AB-E2CD585F311D@sabot-durand.net> Hi all, You may have followed the rise and fall of the Java Config JSR (http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html ). Anatole in CC was leading this initiative and I proposed him to join us and explore if some part of his late-JSR could be done in CDI. I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or related solution. If we achieve to have a majority of specs to integrate with CDI, our configuration solution would therefore become a configuration system for all spec based on CDI 2.0. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/7794774f/attachment.html From thjanssen123 at gmail.com Fri Sep 5 09:28:29 2014 From: thjanssen123 at gmail.com (Thorben Janssen) Date: Fri, 5 Sep 2014 15:28:29 +0200 Subject: [cdi-dev] Tools : Google Drive vs Asciidoc and Github In-Reply-To: References: Message-ID: +1 -- *Thorben Janssen* @thjanssen123 www.thoughts-on-java.org 2014-09-05 15:02 GMT+02:00 Antonio Goncalves : > +1 > > > On Fri, Sep 5, 2014 at 12:22 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi all, >> >> >> To pursue the discussion we had during last meeting, I really think we >> should use both tools for the workshop. that?s how I see things : >> >> In early stage in the workshop the working doc is changing fast and could >> probably content ideas that will disappear in future version (impossible or >> breaking backward compatibility). >> This phase needs fast collaboration between people knowing that the doc >> content is volatile and more in ?brain storm? than in ?part of the final >> spec? mode. For these reason I think we should set this working phase in >> Google Drive. It will be easier to collaborate synchronously on the doc and >> separate the very early draft to more advance phase. >> >> When an agreement (we have to define that yet) will be reached on this >> doc, it will be converted in Asciidoc (the plugin works nicely) and >> integrated to the spec website. The change will course continue but if we >> didn?t missed big mistake there will be less of them and they could be done >> thru PR. >> >> WDYT ? >> >> 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. > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > > _______________________________________________ > 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/20140905/20d4093a/attachment.html From antonio.goncalves at gmail.com Fri Sep 5 10:08:03 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Fri, 5 Sep 2014 16:08:03 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: <20184D0D-5AE3-4FF8-B2AB-E2CD585F311D@sabot-durand.net> References: <20184D0D-5AE3-4FF8-B2AB-E2CD585F311D@sabot-durand.net> Message-ID: One wise man* once said "EJB was a hype specification, we added too many things to it, it became bloated. The next hype specifications are JAX-RS and CDI, careful with them" Either we get this idea of "parts" right, or CDI will endup being bloated. Antonio *David Blevin On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > You may have followed the rise and fall of the Java Config JSR ( > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > ). > Anatole in CC was leading this initiative and I proposed him to join us > and explore if some part of his late-JSR could be done in CDI. > > I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or related > solution. If we achieve to have a majority of specs to integrate with CDI, > our configuration solution would therefore become a configuration system > for all spec based on CDI 2.0. > > 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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/a30fb658/attachment-0001.html From issues at jboss.org Fri Sep 5 10:17:04 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 5 Sep 2014 10:17:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999414#comment-12999414 ] Martin Kouba commented on CDI-4: -------------------------------- [~agoncal] {{javax.annotation.Priority}} has {{@Target(value=TYPE)}} so we can't use it for observer methods :-( > Need a way to provide ordering for Event observers > -------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: 2.0 (discussion) > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From werner.keil at gmail.com Fri Sep 5 10:18:13 2014 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 5 Sep 2014 16:18:13 +0200 Subject: [cdi-dev] cdi-dev Digest, Vol 46, Issue 16 In-Reply-To: References: Message-ID: Antonio/all, I fully agree. Looking at some of the highly redundant stuff (like improving and extending java.util.Calendar, beside adding JavaFX with its own isolated Date/Time solution and an almost identical Duration type in JSR 310, which itself is full of redundancies and bloating, adding ~2MB or more to the JDK without any new business value that isn't archieved by the other 3! Date/Time APIs JDK already has including FX) in Java SE 8, we must get a better solution for CDI 2, even without Jigsaw or any JDK modularization (where if done right, you could then chose to add JavaFX, JSR 310 or other stuff or just leave the "bloatware" if your app doesn't need it;-D) JSRs like MEEP 8 (on the ME side) or 363 (also modular and portable across both ME 8 and varous SE versions) demonstrated how this can work, and Agorava, a "fallout" of JSR 357 using many aspects of CDI 1.x and DeltaSpike already are great examples how this could work for CDI 2, as well. Regards, Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Java Godfather Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps Skype werner.keil | Google+ gplus.to/wernerkeil * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life Science and the Internet of Everything" * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP EC Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend or FOE" * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class DevOps", "JSR 363" * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache DeviceMap" (GER) * ApacheCon Europe: 17-21 Nov 2014, Budapest, Hungary. Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache DeviceMap" On Fri, Sep 5, 2014 at 4:08 PM, 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. Re: Tools : Google Drive vs Asciidoc and Github (Pete Muir) > 2. Re: Tools : Google Drive vs Asciidoc and Github (Mark Paluch) > 3. Re: Tools : Google Drive vs Asciidoc and Github > (Antonio Goncalves) > 4. With the end of Java Config... (Antoine Sabot-Durand) > 5. Re: Tools : Google Drive vs Asciidoc and Github (Thorben Janssen) > 6. Re: With the end of Java Config... (Antonio Goncalves) > > ------------------------------ > > Message: 6 > Date: Fri, 5 Sep 2014 16:08:03 +0200 > From: Antonio Goncalves > Subject: Re: [cdi-dev] With the end of Java Config... > To: Antoine Sabot-Durand > Cc: cdi-dev > Message-ID: > < > CA+ZZq9-2mNdubTWztFM5kqLOi+AKRM4RLB0pcDY-NP5WKUVFPQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > One wise man* once said "EJB was a hype specification, we added too many > things to it, it became bloated. The next hype specifications are JAX-RS > and CDI, careful with them" > > Either we get this idea of "parts" right, or CDI will endup being bloated. > > Antonio > > > *David Blevin > > > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > > Hi all, > > > > You may have followed the rise and fall of the Java Config JSR ( > > > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > > ). > > Anatole in CC was leading this initiative and I proposed him to join us > > and explore if some part of his late-JSR could be done in CDI. > > > > I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or > related > > solution. If we achieve to have a majority of specs to integrate with > CDI, > > our configuration solution would therefore become a configuration system > > for all spec based on CDI 2.0. > > > > 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. > > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn < > http://www.linkedin.com/in/agoncal> | > Pluralsight > | > Paris > JUG | Devoxx France > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/a30fb658/attachment.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 46, Issue 16 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/db3a2042/attachment.html From john.d.ament at gmail.com Fri Sep 5 10:24:37 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Fri, 5 Sep 2014 10:24:37 -0400 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <20184D0D-5AE3-4FF8-B2AB-E2CD585F311D@sabot-durand.net> Message-ID: Agreed w/ Antonio. JAX-RS did the right thing by making MVC a separate spec. While we can provide a way to wire up beans externally w/ an XML DSL, I don't think we should get into the business of config properties,etc. On Fri, Sep 5, 2014 at 10:08 AM, Antonio Goncalves < antonio.goncalves at gmail.com> wrote: > One wise man* once said "EJB was a hype specification, we added too many > things to it, it became bloated. The next hype specifications are JAX-RS > and CDI, careful with them" > > Either we get this idea of "parts" right, or CDI will endup being bloated. > > Antonio > > > *David Blevin > > > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi all, >> >> You may have followed the rise and fall of the Java Config JSR ( >> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >> ). >> Anatole in CC was leading this initiative and I proposed him to join us >> and explore if some part of his late-JSR could be done in CDI. >> >> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >> related solution. If we achieve to have a majority of specs to integrate >> with CDI, our configuration solution would therefore become a configuration >> system for all spec based on CDI 2.0. >> >> 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. >> > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > > _______________________________________________ > 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/20140905/2ab10644/attachment-0001.html From john.d.ament at gmail.com Fri Sep 5 10:36:31 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Fri, 5 Sep 2014 10:36:31 -0400 Subject: [cdi-dev] Tools : Google Drive vs Asciidoc and Github In-Reply-To: References: Message-ID: +1 On Fri, Sep 5, 2014 at 6:22 AM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > > To pursue the discussion we had during last meeting, I really think we > should use both tools for the workshop. that?s how I see things : > > In early stage in the workshop the working doc is changing fast and could > probably content ideas that will disappear in future version (impossible or > breaking backward compatibility). > This phase needs fast collaboration between people knowing that the doc > content is volatile and more in ?brain storm? than in ?part of the final > spec? mode. For these reason I think we should set this working phase in > Google Drive. It will be easier to collaborate synchronously on the doc and > separate the very early draft to more advance phase. > > When an agreement (we have to define that yet) will be reached on this > doc, it will be converted in Asciidoc (the plugin works nicely) and > integrated to the spec website. The change will course continue but if we > didn?t missed big mistake there will be less of them and they could be done > thru PR. > > WDYT ? > > 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/20140905/13806ccc/attachment.html From werner.keil at gmail.com Fri Sep 5 10:43:57 2014 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 5 Sep 2014 16:43:57 +0200 Subject: [cdi-dev] With the end of Java Config... Message-ID: You got a point, but so far both Oracle and Red Hat dismissed the idea of a separate Config JSR. Anatole was in touch with both of them and either their resources or interest seemed to lack. It is quite a shamble, that e.g. JSR 107 already went down the path of a completely separate Config sub-system ( https://github.com/jsr107/jsr107spec/tree/master/src/main/java/javax/cache/configuration) while pruning other much more importent (especially for true EE 8 value) features like Transaction Support in line with JTA, etc. If CDI2 needed a config sub-system, too, we better avoid their mistake or (for EE 8 since it is considered for inclusion) look at ways this may work together in some unified way. Whether it's a separate JSR or "Module" of CDI 2 I don't really care, but we must not fall into the same "Not invented Here" trap as Java SE did with all its redundant and bloated features like JavaFX having its own Date/Time same as java.util.Date (which aside from JSR 236 also is the only one relevant to EE, JDBC, etc.) or the extra package java.time. JCache already went in the wrong direction here, as it is final there is probably not a lot to do, but do we really want to end up with - JCache-config - CDI-config - MVC-config ... ??;-O Werner On Fri, Sep 5, 2014 at 4:24 PM, 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. [JBoss JIRA] (CDI-4) Need a way to provide ordering for Event > observers (Martin Kouba (JIRA)) > 2. Re: cdi-dev Digest, Vol 46, Issue 16 (Werner Keil) > 3. Re: With the end of Java Config... (John D. Ament) > > ------------------------------ > > Message: 3 > Date: Fri, 5 Sep 2014 10:24:37 -0400 > From: "John D. Ament" > Subject: Re: [cdi-dev] With the end of Java Config... > To: Antonio Goncalves > Cc: cdi-dev > Message-ID: > < > CAOqetn8UrpdWEFV8LJJ57hJ+z-iAFNjEEzyqsfPXFUQutuqT8A at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Agreed w/ Antonio. JAX-RS did the right thing by making MVC a separate > spec. While we can provide a way to wire up beans externally w/ an XML > DSL, I don't think we should get into the business of config > properties,etc. > > > On Fri, Sep 5, 2014 at 10:08 AM, Antonio Goncalves < > antonio.goncalves at gmail.com> wrote: > > > One wise man* once said "EJB was a hype specification, we added too many > > things to it, it became bloated. The next hype specifications are JAX-RS > > and CDI, careful with them" > > > > Either we get this idea of "parts" right, or CDI will endup being > bloated. > > > > Antonio > > > > > > *David Blevin > > > > > > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < > > antoine at sabot-durand.net> wrote: > > > >> Hi all, > >> > >> You may have followed the rise and fall of the Java Config JSR ( > >> > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > >> ). > >> Anatole in CC was leading this initiative and I proposed him to join us > >> and explore if some part of his late-JSR could be done in CDI. > >> > >> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or > >> related solution. If we achieve to have a majority of specs to integrate > >> with CDI, our configuration solution would therefore become a > configuration > >> system for all spec based on CDI 2.0. > >> > >> 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. > >> > > > > > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter > > | LinkedIn > > | Pluralsight > > | > Paris > > JUG | Devoxx France > > > > _______________________________________________ > > 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/20140905/2ab10644/attachment.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 46, Issue 17 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/95777c35/attachment.html From pmuir at redhat.com Fri Sep 5 10:50:41 2014 From: pmuir at redhat.com (Pete Muir) Date: Fri, 5 Sep 2014 15:50:41 +0100 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: Message-ID: I would just like to note that we definitely support the idea of a Config JSR. And we would provide strong EG representation, and help with RI/TCK. However we are unable to take a lead role in it right now, due to having many other things going on. On 5 Sep 2014, at 15:43, Werner Keil wrote: > You got a point, but so far both Oracle and Red Hat dismissed the idea of a separate Config JSR. Anatole was in touch with both of them and either their resources or interest seemed to lack. > > It is quite a shamble, that e.g. JSR 107 already went down the path of a completely separate Config sub-system (https://github.com/jsr107/jsr107spec/tree/master/src/main/java/javax/cache/configuration) while pruning other much more importent (especially for true EE 8 value) features like Transaction Support in line with JTA, etc. > > If CDI2 needed a config sub-system, too, we better avoid their mistake or (for EE 8 since it is considered for inclusion) look at ways this may work together in some unified way. > Whether it's a separate JSR or "Module" of CDI 2 I don't really care, but we must not fall into the same "Not invented Here" trap as Java SE did with all its redundant and bloated features like JavaFX having its own Date/Time same as java.util.Date (which aside from JSR 236 also is the only one relevant to EE, JDBC, etc.) or the extra package java.time. > > JCache already went in the wrong direction here, as it is final there is probably not a lot to do, but do we really want to end up with > - JCache-config > - CDI-config > - MVC-config > ... > > ??;-O > > Werner > > On Fri, Sep 5, 2014 at 4:24 PM, 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. [JBoss JIRA] (CDI-4) Need a way to provide ordering for Event > observers (Martin Kouba (JIRA)) > 2. Re: cdi-dev Digest, Vol 46, Issue 16 (Werner Keil) > 3. Re: With the end of Java Config... (John D. Ament) > > ------------------------------ > > Message: 3 > Date: Fri, 5 Sep 2014 10:24:37 -0400 > From: "John D. Ament" > Subject: Re: [cdi-dev] With the end of Java Config... > To: Antonio Goncalves > Cc: cdi-dev > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Agreed w/ Antonio. JAX-RS did the right thing by making MVC a separate > spec. While we can provide a way to wire up beans externally w/ an XML > DSL, I don't think we should get into the business of config properties,etc. > > > On Fri, Sep 5, 2014 at 10:08 AM, Antonio Goncalves < > antonio.goncalves at gmail.com> wrote: > > > One wise man* once said "EJB was a hype specification, we added too many > > things to it, it became bloated. The next hype specifications are JAX-RS > > and CDI, careful with them" > > > > Either we get this idea of "parts" right, or CDI will endup being bloated. > > > > Antonio > > > > > > *David Blevin > > > > > > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < > > antoine at sabot-durand.net> wrote: > > > >> Hi all, > >> > >> You may have followed the rise and fall of the Java Config JSR ( > >> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > >> ). > >> Anatole in CC was leading this initiative and I proposed him to join us > >> and explore if some part of his late-JSR could be done in CDI. > >> > >> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or > >> related solution. If we achieve to have a majority of specs to integrate > >> with CDI, our configuration solution would therefore become a configuration > >> system for all spec based on CDI 2.0. > >> > >> 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. > >> > > > > > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter > > | LinkedIn > > | Pluralsight > > | Paris > > JUG | Devoxx France > > > > _______________________________________________ > > 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/20140905/2ab10644/attachment.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 46, Issue 17 > *************************************** > > _______________________________________________ > 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 werner.keil at gmail.com Fri Sep 5 11:12:56 2014 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 5 Sep 2014 17:12:56 +0200 Subject: [cdi-dev] With the end of Java Config... Message-ID: Pete/all Thanks for the clarification. It seems, otherwise he would not have pointed out the issue in the first place, Anatole is also not able even as a Co Spec Lead to take a driving seat on that. I am Co Spec Lead of JSR 363 - Unit of Measurement (which especially in the SE implementation optimized for SE/EE 8+ seems like there are synergies for a typesafe definition of config elements;-) ) so other than assisting one or the other Spec Lead found for this I do not see reason to take more than one Spec Lead responsibility at a time, otherwise, jut look at the misery of JSR 310 or 107;-D Are there any observers/experts here or in EE 8 that would feel like helping lead such a JSR? Anatole and I also spoke to CloudBees (a company you sure know well) and there was general interest, but I recall they had slightly different views on some things, but as EG Member both they and maybe other players (e.g. Pivotal or someone from DeltaSpike both with an approach to config) would be qualified EG Members or Co Spec Leads for this. As you know it would be best if a true Individual who is self employed (e.g. Antonio?;-)) did this, otherwise an employee of a company, even more if they have something to do with Java could run into IP and patent troubles, I talk from the experience in EC and IP WG of JSR 358;-) Anybody willing and able to help? I'll be at JavaZone next week, speaking with e.g. Arun or (EE EG Member) Jeff Genender, so if there is no sound interest in this list, we can certainly talk about it in Oslo, too. Werner On Fri, Sep 5, 2014 at 4:50 PM, Pete Muir wrote: > I would just like to note that we definitely support the idea of a Config > JSR. And we would provide strong EG representation, and help with RI/TCK. > However we are unable to take a lead role in it right now, due to having > many other things going on. > > On 5 Sep 2014, at 15:43, Werner Keil wrote: > > > You got a point, but so far both Oracle and Red Hat dismissed the idea > of a separate Config JSR. Anatole was in touch with both of them and either > their resources or interest seemed to lack. > > > > It is quite a shamble, that e.g. JSR 107 already went down the path of a > completely separate Config sub-system ( > https://github.com/jsr107/jsr107spec/tree/master/src/main/java/javax/cache/configuration) > while pruning other much more importent (especially for true EE 8 value) > features like Transaction Support in line with JTA, etc. > > > > If CDI2 needed a config sub-system, too, we better avoid their mistake > or (for EE 8 since it is considered for inclusion) look at ways this may > work together in some unified way. > > Whether it's a separate JSR or "Module" of CDI 2 I don't really care, > but we must not fall into the same "Not invented Here" trap as Java SE did > with all its redundant and bloated features like JavaFX having its own > Date/Time same as java.util.Date (which aside from JSR 236 also is the only > one relevant to EE, JDBC, etc.) or the extra package java.time. > > > > JCache already went in the wrong direction here, as it is final there is > probably not a lot to do, but do we really want to end up with > > - JCache-config > > - CDI-config > > - MVC-config > > ... > > > > ??;-O > > > > Werner > > > > On Fri, Sep 5, 2014 at 4:24 PM, 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. [JBoss JIRA] (CDI-4) Need a way to provide ordering for Event > > observers (Martin Kouba (JIRA)) > > 2. Re: cdi-dev Digest, Vol 46, Issue 16 (Werner Keil) > > 3. Re: With the end of Java Config... (John D. Ament) > > > > ------------------------------ > > > > Message: 3 > > Date: Fri, 5 Sep 2014 10:24:37 -0400 > > From: "John D. Ament" > > Subject: Re: [cdi-dev] With the end of Java Config... > > To: Antonio Goncalves > > Cc: cdi-dev > > Message-ID: > > < > CAOqetn8UrpdWEFV8LJJ57hJ+z-iAFNjEEzyqsfPXFUQutuqT8A at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Agreed w/ Antonio. JAX-RS did the right thing by making MVC a separate > > spec. While we can provide a way to wire up beans externally w/ an XML > > DSL, I don't think we should get into the business of config > properties,etc. > > > > > > On Fri, Sep 5, 2014 at 10:08 AM, Antonio Goncalves < > > antonio.goncalves at gmail.com> wrote: > > > > > One wise man* once said "EJB was a hype specification, we added too > many > > > things to it, it became bloated. The next hype specifications are > JAX-RS > > > and CDI, careful with them" > > > > > > Either we get this idea of "parts" right, or CDI will endup being > bloated. > > > > > > Antonio > > > > > > > > > *David Blevin > > > > > > > > > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < > > > antoine at sabot-durand.net> wrote: > > > > > >> Hi all, > > >> > > >> You may have followed the rise and fall of the Java Config JSR ( > > >> > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > > >> ). > > >> Anatole in CC was leading this initiative and I proposed him to join > us > > >> and explore if some part of his late-JSR could be done in CDI. > > >> > > >> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or > > >> related solution. If we achieve to have a majority of specs to > integrate > > >> with CDI, our configuration solution would therefore become a > configuration > > >> system for all spec based on CDI 2.0. > > >> > > >> 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. > > >> > > > > > > > > > > > > -- > > > Antonio Goncalves > > > Software architect, Java Champion and Pluralsight author > > > > > > Web site | Twitter > > > | LinkedIn > > > | Pluralsight > > > | > Paris > > > JUG | Devoxx France > > > > > > _______________________________________________ > > > 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/20140905/2ab10644/attachment.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 46, Issue 17 > > *************************************** > > > > _______________________________________________ > > 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/20140905/bb0e433b/attachment.html From issues at jboss.org Fri Sep 5 11:35:02 2014 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Fri, 5 Sep 2014 11:35:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999465#comment-12999465 ] Antonio Goncalves commented on CDI-4: ------------------------------------- [~martinkouba] There was a maintenance release during Java EE 7 for the [JSR 250|https://jcp.org/en/jsr/detail?id=250], it can be updated again on Java EE 8 if needed. > Need a way to provide ordering for Event observers > -------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: 2.0 (discussion) > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From omeuefilipe at gmail.com Fri Sep 5 14:43:44 2014 From: omeuefilipe at gmail.com (Filipe Portes) Date: Fri, 5 Sep 2014 15:43:44 -0300 Subject: [cdi-dev] Tools : Google Drive vs Asciidoc and Github In-Reply-To: References: Message-ID: agreed On Fri, Sep 5, 2014 at 11:36 AM, John D. Ament wrote: > +1 > > > On Fri, Sep 5, 2014 at 6:22 AM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi all, >> >> >> To pursue the discussion we had during last meeting, I really think we >> should use both tools for the workshop. that?s how I see things : >> >> In early stage in the workshop the working doc is changing fast and could >> probably content ideas that will disappear in future version (impossible or >> breaking backward compatibility). >> This phase needs fast collaboration between people knowing that the doc >> content is volatile and more in ?brain storm? than in ?part of the final >> spec? mode. For these reason I think we should set this working phase in >> Google Drive. It will be easier to collaborate synchronously on the doc and >> separate the very early draft to more advance phase. >> >> When an agreement (we have to define that yet) will be reached on this >> doc, it will be converted in Asciidoc (the plugin works nicely) and >> integrated to the spec website. The change will course continue but if we >> didn?t missed big mistake there will be less of them and they could be done >> thru PR. >> >> WDYT ? >> >> 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. > -- Filipe Portes - @filipeportes Senior Java EE/Web JUGLeader Gojava - @gojava -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/1370bd3e/attachment-0001.html From atsticks at gmail.com Fri Sep 5 14:58:35 2014 From: atsticks at gmail.com (Anatole Tresch) Date: Fri, 5 Sep 2014 20:58:35 +0200 Subject: [cdi-dev] Tools : Google Drive vs Asciidoc and Github In-Reply-To: References: Message-ID: Hi All I would definitively recommend this. With JSR 354 (Money) we basically did the same. Collaboration is easy, effective and it is also very easy to spread things for feedback and to remove things, if they were closed/moved (e.g. with a EDR). For final uniform formatting (especially title numbering, which is not supported by Google Docs), links etc. Asciidcoc is definitively the better solution. Cheers, Anatole 2014-09-05 12:22 GMT+02:00 Antoine Sabot-Durand : > Hi all, > > > To pursue the discussion we had during last meeting, I really think we > should use both tools for the workshop. that?s how I see things : > > In early stage in the workshop the working doc is changing fast and could > probably content ideas that will disappear in future version (impossible or > breaking backward compatibility). > This phase needs fast collaboration between people knowing that the doc > content is volatile and more in ?brain storm? than in ?part of the final > spec? mode. For these reason I think we should set this working phase in > Google Drive. It will be easier to collaborate synchronously on the doc and > separate the very early draft to more advance phase. > > When an agreement (we have to define that yet) will be reached on this > doc, it will be converted in Asciidoc (the plugin works nicely) and > integrated to the spec website. The change will course continue but if we > didn?t missed big mistake there will be less of them and they could be done > thru PR. > > WDYT ? > > 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. -- *Anatole Tresch* Java Lead Engineer, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/cc53644d/attachment.html From atsticks at gmail.com Fri Sep 5 15:22:20 2014 From: atsticks at gmail.com (Anatole Tresch) Date: Fri, 5 Sep 2014 21:22:20 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <20184D0D-5AE3-4FF8-B2AB-E2CD585F311D@sabot-durand.net> Message-ID: Hi all, I would not like to add an XML "bloated" mechanism as part of CDI 2.0. Spontaneously I would propose a more CDI like things like: - Adding a @Configured annotation (basically a qualifier). This can be in addition to @Inject and would allow to inject "configured" values. - Since configuration can change we may think of a (CDI) event/reinject mechanism based on config changes. By default, this is switched off and we can discuss how it would be activated, e.g. by an additional flag settable with the @Configured annotation, or an additional @Observable ConfigChangeEvent (similar to the Griffon framework), or both. - Hereby configured values theoretically behave *similar *as all other injection points. They also can be qualified (the aspect of scopes, I did not yet have time to think about). The only difference is, that they are satisified using the configuration "system". - The configuration "source" itself could in the extreme simplest way be a Provider>. The CDI spec should not care about how this map is provided (XML, DB, overrides, etc). This still can be standardized later. As long as the ConfigurationSource SPI is defined, companies still can hook in the logic and level of configuration abstraction they need. - Of course, since not only Strings can be injected, we need some *conversion or adapter logic *as basically outlined in my blog. Also here we can add a simple SPI and let the details to the RI. Summarizing a - @Configured annotation - some kind of change event - a ConfigurationSource extends Provider> - a conversion mechanism from String to T. we get a full fledged configuration mechanism that leverages CDI. That would be my idea basically. WDYT? I will try to work that out in more details. Basically it should be implementable even with the CDI mechanism already in place with CDI 1.1. Best, Anatole 2014-09-05 16:08 GMT+02:00 Antonio Goncalves : > One wise man* once said "EJB was a hype specification, we added too many > things to it, it became bloated. The next hype specifications are JAX-RS > and CDI, careful with them" > > Either we get this idea of "parts" right, or CDI will endup being bloated. > > Antonio > > > *David Blevin > > > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi all, >> >> You may have followed the rise and fall of the Java Config JSR ( >> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >> ). >> Anatole in CC was leading this initiative and I proposed him to join us >> and explore if some part of his late-JSR could be done in CDI. >> >> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >> related solution. If we achieve to have a majority of specs to integrate >> with CDI, our configuration solution would therefore become a configuration >> system for all spec based on CDI 2.0. >> >> 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. >> > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > > _______________________________________________ > 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. > -- *Anatole Tresch* Java Lead Engineer, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/0e7579de/attachment.html From issues at jboss.org Fri Sep 5 16:01:05 2014 From: issues at jboss.org (Anatole Tresch (JIRA)) Date: Fri, 5 Sep 2014 16:01:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999582#comment-12999582 ] Anatole Tresch commented on CDI-456: ------------------------------------ Jozef, imagine the following {noformat} public class MyProducer{ @Produces @ApplicationScoped public MyBean create(){ return new MyBean(); } } {noformat} The {{MyBean}} class is declared in the *ear*, as follows: {noformat} public final class MyBean{ public final String CONTEXT = Thread.currentThread().getContextClassLoader().toString(); } {noformat} Now you have 3 wars, the class instance for {{MyBean}} will be the same for all three wars, since it is loaded from the *ear classloader* (but also visible to the war classloader). Nevertheless, since the {{MyProducer}} producer class is defined on *war level*, you get three different instances, each with a different {{CONTEXT}}... > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From jens.schumann at openknowledge.de Fri Sep 5 16:20:53 2014 From: jens.schumann at openknowledge.de (Jens Schumann) Date: Fri, 5 Sep 2014 20:20:53 +0000 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <20184D0D-5AE3-4FF8-B2AB-E2CD585F311D@sabot-durand.net> Message-ID: I can confirm that this approach works very well. We are using a similar approach a couple of years now, and I love the simplicity that comes with portable extensions and @Producer methods. See our public version here [1] (works since early CDI 1.0 days) . Instead of a @Inject + Qualifier we just use the qualifier @Property. We support default values and type conversation for primitives and everything that has a string based constructor. The property source can be anything, from property files (default) to databases or xml files. For examples see tests here [2]. Nevertheless I am not sure if this should be part of an future CDI spec. My concerns include the bloat argument, of course. But the main reason relates to the fact that we have almost everything in the current CDI spec already. Right now I am quite happy with an custom portable extension that does everything for me. At the time we implemented the extension we realised that the "hard part" was writing an extension that links a qualified "optional injection point" with an @Producer method while supporting code based default values. Luckily I had Arne in my team who did that within a few minutes. Because of this experience I would propose that we simplify extension development such that "optional injection points" may be linked to @Produces values easily. Additionally we have to solve a few more integration issues (e.g. read-only DB access should be available during CDI startup). Everything else should be provided by portable extensions (e.g. via delta-spike) and documentation/howtos at cdi-spec.org. Jens [1] https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property [2] https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property Von: Anatole Tresch > Datum: Friday 5 September 2014 21:22 An: Antonio Goncalves > Cc: CDI-Dev > Betreff: Re: [cdi-dev] With the end of Java Config... Hi all, I would not like to add an XML "bloated" mechanism as part of CDI 2.0. Spontaneously I would propose a more CDI like things like: * Adding a @Configured annotation (basically a qualifier). This can be in addition to @Inject and would allow to inject "configured" values. * Since configuration can change we may think of a (CDI) event/reinject mechanism based on config changes. By default, this is switched off and we can discuss how it would be activated, e.g. by an additional flag settable with the @Configured annotation, or an additional @Observable ConfigChangeEvent (similar to the Griffon framework), or both. * Hereby configured values theoretically behave similar as all other injection points. They also can be qualified (the aspect of scopes, I did not yet have time to think about). The only difference is, that they are satisified using the configuration "system". * The configuration "source" itself could in the extreme simplest way be a Provider>. The CDI spec should not care about how this map is provided (XML, DB, overrides, etc). This still can be standardized later. As long as the ConfigurationSource SPI is defined, companies still can hook in the logic and level of configuration abstraction they need. * Of course, since not only Strings can be injected, we need some conversion or adapter logic as basically outlined in my blog. Also here we can add a simple SPI and let the details to the RI. Summarizing a * @Configured annotation * some kind of change event * a ConfigurationSource extends Provider> * a conversion mechanism from String to T. we get a full fledged configuration mechanism that leverages CDI. That would be my idea basically. WDYT? I will try to work that out in more details. Basically it should be implementable even with the CDI mechanism already in place with CDI 1.1. Best, Anatole 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >: One wise man* once said "EJB was a hype specification, we added too many things to it, it became bloated. The next hype specifications are JAX-RS and CDI, careful with them" Either we get this idea of "parts" right, or CDI will endup being bloated. Antonio *David Blevin On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand > wrote: Hi all, You may have followed the rise and fall of the Java Config JSR (http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html). Anatole in CC was leading this initiative and I proposed him to join us and explore if some part of his late-JSR could be done in CDI. I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or related solution. If we achieve to have a majority of specs to integrate with CDI, our configuration solution would therefore become a configuration system for all spec based on CDI 2.0. 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. -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France _______________________________________________ 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. -- Anatole Tresch Java Lead Engineer, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon Switzerland, Europe Zurich, GMT+1 Twitter: @atsticks Blogs: http://javaremarkables.blogspot.ch/ Google: atsticks Mobile +41-76 344 62 79 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment-0001.html From werner.keil at gmail.com Fri Sep 5 17:30:14 2014 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 5 Sep 2014 23:30:14 +0200 Subject: [cdi-dev] With the end of Java Config... Message-ID: Jens/all, A sort of "staging" already was possible using CDI earlier, see examples like this: http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war DeltaSpike also includes type-safe staging that goes beyond the primitive, hard-coded JSF enum. If that works without XML, while still allowing flexible configuration for different stages or to add and "inject" additional stages maybe even on a tenant basis (for Cloud scenarios) I could see something like that work without XML. In the Multiconf project we managed to code everything in Python, and similar to Puppet or Chef you can configure and deploy multiple environments with it, Java EE, Spring or Play! several of them are configured this way and it requires no XML (where the container needs such files, the framework generates them;-) Werner On Fri, Sep 5, 2014 at 10:21 PM, 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) > 2. Re: With the end of Java Config... (Anatole Tresch) > 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition > (Anatole Tresch (JIRA)) > 4. Re: With the end of Java Config... (Jens Schumann) > > ------------------------------ > > Message: 4 > Date: Fri, 5 Sep 2014 20:20:53 +0000 > From: Jens Schumann > Subject: Re: [cdi-dev] With the end of Java Config... > To: Anatole Tresch , Antonio Goncalves > > Cc: cdi-dev > Message-ID: > Content-Type: text/plain; charset="windows-1252" > > I can confirm that this approach works very well. We are using a similar > approach a couple of years now, and I love the simplicity that comes with > portable extensions and @Producer methods. See our public version here [1] > (works since early CDI 1.0 days) . > > Instead of a @Inject + Qualifier we just use the qualifier @Property. We > support default values and type conversation for primitives and everything > that has a string based constructor. The property source can be anything, > from property files (default) to databases or xml files. For examples see > tests here [2]. > > Nevertheless I am not sure if this should be part of an future CDI spec. > My concerns include the bloat argument, of course. But the main reason > relates to the fact that we have almost everything in the current CDI spec > already. > > Right now I am quite happy with an custom portable extension that does > everything for me. At the time we implemented the extension we realised > that the "hard part" was writing an extension that links a qualified > "optional injection point" with an @Producer method while supporting code > based default values. Luckily I had Arne in my team who did that within a > few minutes. > > Because of this experience I would propose that we simplify extension > development such that "optional injection points" may be linked to > @Produces values easily. Additionally we have to solve a few more > integration issues (e.g. read-only DB access should be available during CDI > startup). Everything else should be provided by portable extensions (e.g. > via delta-spike) and documentation/howtos at cdi-spec.org. > > Jens > [1] > https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property > [2] > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property > > Von: Anatole Tresch > > Datum: Friday 5 September 2014 21:22 > An: Antonio Goncalves antonio.goncalves at gmail.com>> > Cc: CDI-Dev > > Betreff: Re: [cdi-dev] With the end of Java Config... > > Hi all, > > I would not like to add an XML "bloated" mechanism as part of CDI 2.0. > Spontaneously I would propose a more CDI like things like: > > > * Adding a @Configured annotation (basically a qualifier). This can be > in addition to @Inject and would allow to inject "configured" values. > * Since configuration can change we may think of a (CDI) > event/reinject mechanism based on config changes. By default, this is > switched off and we can discuss how it would be activated, e.g. by an > additional flag settable with the @Configured annotation, or an additional > @Observable ConfigChangeEvent (similar to the Griffon framework), or both. > * Hereby configured values theoretically behave similar as all other > injection points. They also can be qualified (the aspect of scopes, I did > not yet have time to think about). The only difference is, that they are > satisified using the configuration "system". > * The configuration "source" itself could in the extreme simplest way > be a Provider>. The CDI spec should not care about how > this map is provided (XML, DB, overrides, etc). This still can be > standardized later. As long as the ConfigurationSource SPI is defined, > companies still can hook in the logic and level of configuration > abstraction they need. > * Of course, since not only Strings can be injected, we need some > conversion or adapter logic as basically outlined in my blog. Also here we > can add a simple SPI and let the details to the RI. > > Summarizing a > > * @Configured annotation > * some kind of change event > * a ConfigurationSource extends Provider> > * a conversion mechanism from String to T. > > we get a full fledged configuration mechanism that leverages CDI. > > That would be my idea basically. WDYT? I will try to work that out in more > details. Basically it should be implementable even with the CDI mechanism > already in place with CDI 1.1. > > Best, > Anatole > > > > > > > 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >: > One wise man* once said "EJB was a hype specification, we added too many > things to it, it became bloated. The next hype specifications are JAX-RS > and CDI, careful with them" > > Either we get this idea of "parts" right, or CDI will endup being bloated. > > Antonio > > > *David Blevin > > > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > Hi all, > > You may have followed the rise and fall of the Java Config JSR ( > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > ). > Anatole in CC was leading this initiative and I proposed him to join us > and explore if some part of his late-JSR could be done in CDI. > > I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or related > solution. If we achieve to have a majority of specs to integrate with CDI, > our configuration solution would therefore become a configuration system > for all spec based on CDI 2.0. > > 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. > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter< > http://twitter.com/agoncal> | LinkedIn > | Pluralsight< > http://pluralsight.com/training/Authors/Details/antonio-goncalves> | > Paris JUG | Devoxx France > > _______________________________________________ > 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. > > > > -- > Anatole Tresch > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > Switzerland, Europe Zurich, GMT+1 > Twitter: @atsticks > Blogs: http://javaremarkables.blogspot.ch/ > Google: atsticks > Mobile +41-76 344 62 79 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/5b8f8c91/attachment.html From atsticks at gmail.com Fri Sep 5 18:07:57 2014 From: atsticks at gmail.com (Anatole Tresch) Date: Sat, 6 Sep 2014 00:07:57 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <20184D0D-5AE3-4FF8-B2AB-E2CD585F311D@sabot-durand.net> Message-ID: One advantage of adding it to the spec is that - we have a standard: so as a company I can request my third party providers to built upon exact this standard way for configuration. And with the SPIs I know well how I can interconnect this functionality with my deployment infrastructure/company configuration. - this was only a bare minimal proposal. Basically Configuration should also be capable of configuring CDI itself, e.g. activating alternatives, interceptors, decorators etc. This something where "ordinary extensions" may fail... - the ladder may lead to some kind of ConfigurationService that might be used by the CDI container, but also might be accessible (e.g. via JNDI) without CDI. With that even legacy and other special use cases (which are still common) could be covered, including possible support for Java SE on a very basic level. Cheers, Anatole 2014-09-05 22:20 GMT+02:00 Jens Schumann : > I can confirm that this approach works very well. We are using a similar > approach a couple of years now, and I love the simplicity that comes with > portable extensions and @Producer methods. See our public version here [1] > (works since early CDI 1.0 days) . > > Instead of a @Inject + Qualifier we just use the qualifier @Property. We > support default values and type conversation for primitives and everything > that has a string based constructor. The property source can be anything, > from property files (default) to databases or xml files. For examples see > tests here [2]. > > Nevertheless I am not sure if this should be part of an future CDI spec. > My concerns include the bloat argument, of course. But the main reason > relates to the fact that we have almost everything in the current CDI spec > already. > > Right now I am quite happy with an custom portable extension that does > everything for me. At the time we implemented the extension we realised > that the "hard part" was writing an extension that links a qualified > "optional injection point" with an @Producer method while supporting code > based default values. Luckily I had Arne in my team who did that within a > few minutes. > > Because of this experience I would propose that we simplify extension > development such that "optional injection points" may be linked to > @Produces values easily. Additionally we have to solve a few more > integration issues (e.g. read-only DB access should be available during CDI > startup). Everything else should be provided by portable extensions (e.g. > via delta-spike) and documentation/howtos at cdi-spec.org. > > Jens > [1] > https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property > [2] > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property > > Von: Anatole Tresch > Datum: Friday 5 September 2014 21:22 > An: Antonio Goncalves > Cc: CDI-Dev > Betreff: Re: [cdi-dev] With the end of Java Config... > > Hi all, > > I would not like to add an XML "bloated" mechanism as part of CDI 2.0. > Spontaneously I would propose a more CDI like things like: > > > - Adding a @Configured annotation (basically a qualifier). This can be > in addition to @Inject and would allow to inject "configured" values. > - Since configuration can change we may think of a (CDI) > event/reinject mechanism based on config changes. By default, this is > switched off and we can discuss how it would be activated, e.g. by an > additional flag settable with the @Configured annotation, or an > additional @Observable ConfigChangeEvent (similar to the Griffon > framework), or both. > - Hereby configured values theoretically behave *similar *as all other > injection points. They also can be qualified (the aspect of scopes, I did > not yet have time to think about). The only difference is, that they are > satisified using the configuration "system". > - The configuration "source" itself could in the extreme simplest way > be a Provider>. The CDI spec should not care about > how this map is provided (XML, DB, overrides, etc). This still can be > standardized later. As long as the ConfigurationSource SPI is defined, > companies still can hook in the logic and level of configuration > abstraction they need. > - Of course, since not only Strings can be injected, we need some *conversion > or adapter logic *as basically outlined in my blog. Also here we can > add a simple SPI and let the details to the RI. > > Summarizing a > > - @Configured annotation > - some kind of change event > - a ConfigurationSource extends Provider> > - a conversion mechanism from String to T. > > we get a full fledged configuration mechanism that leverages CDI. > > That would be my idea basically. WDYT? I will try to work that out in > more details. Basically it should be implementable even with the CDI > mechanism already in place with CDI 1.1. > > Best, > Anatole > > > > > > > 2014-09-05 16:08 GMT+02:00 Antonio Goncalves > : > >> One wise man* once said "EJB was a hype specification, we added too many >> things to it, it became bloated. The next hype specifications are JAX-RS >> and CDI, careful with them" >> >> Either we get this idea of "parts" right, or CDI will endup being >> bloated. >> >> Antonio >> >> >> *David Blevin >> >> >> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>> Hi all, >>> >>> You may have followed the rise and fall of the Java Config JSR ( >>> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >>> ). >>> Anatole in CC was leading this initiative and I proposed him to join us >>> and explore if some part of his late-JSR could be done in CDI. >>> >>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >>> related solution. If we achieve to have a majority of specs to integrate >>> with CDI, our configuration solution would therefore become a configuration >>> system for all spec based on CDI 2.0. >>> >>> 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. >>> >> >> >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter >> | LinkedIn >> | Pluralsight >> | Paris >> JUG | Devoxx France >> >> _______________________________________________ >> 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. >> > > > > -- > *Anatole Tresch* > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > * > > *Google: atsticks Mobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* > > -- *Anatole Tresch* Java Lead Engineer, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140906/87f7a924/attachment-0001.html From atsticks at gmail.com Fri Sep 5 18:18:25 2014 From: atsticks at gmail.com (Anatole Tresch) Date: Sat, 6 Sep 2014 00:18:25 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: Message-ID: Staging is not a question of xml or not xml (the "format" of config). You can do staged config also using xml, or based on a database or json config service. Staging as well as, more generally speaking, environment dependent config is more like to select/filter the right config that *targets *the current (runtime) environment. This might include stages, but also many other aspects are feasible and common (server, tier, ear, war, tenant ...). Since these aspects are per se very complex, it might be advisable to leave them out of any spec (even a dedicated config JSR would probably not be capable of covering these within the relatively short EE timeframe)... 2014-09-05 23:30 GMT+02:00 Werner Keil : > Jens/all, > > A sort of "staging" already was possible using CDI earlier, see examples > like this: > > http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war > > DeltaSpike also includes type-safe staging that goes beyond the primitive, > hard-coded JSF enum. > > If that works without XML, while still allowing flexible configuration for > different stages or to add and "inject" additional stages maybe even on a > tenant basis (for Cloud scenarios) I could see something like that work > without XML. In the Multiconf project we managed to code everything in > Python, and similar to Puppet or Chef you can configure and deploy multiple > environments with it, Java EE, Spring or Play! several of them are > configured this way and it requires no XML (where the container needs such > files, the framework generates them;-) > > Werner > > On Fri, Sep 5, 2014 at 10:21 PM, 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) >> 2. Re: With the end of Java Config... (Anatole Tresch) >> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >> (Anatole Tresch (JIRA)) >> 4. Re: With the end of Java Config... (Jens Schumann) >> >> ------------------------------ >> >> Message: 4 >> Date: Fri, 5 Sep 2014 20:20:53 +0000 >> From: Jens Schumann >> Subject: Re: [cdi-dev] With the end of Java Config... >> To: Anatole Tresch , Antonio Goncalves >> >> Cc: cdi-dev >> Message-ID: >> Content-Type: text/plain; charset="windows-1252" >> >> I can confirm that this approach works very well. We are using a similar >> approach a couple of years now, and I love the simplicity that comes with >> portable extensions and @Producer methods. See our public version here [1] >> (works since early CDI 1.0 days) . >> >> Instead of a @Inject + Qualifier we just use the qualifier @Property. We >> support default values and type conversation for primitives and everything >> that has a string based constructor. The property source can be anything, >> from property files (default) to databases or xml files. For examples see >> tests here [2]. >> >> Nevertheless I am not sure if this should be part of an future CDI spec. >> My concerns include the bloat argument, of course. But the main reason >> relates to the fact that we have almost everything in the current CDI spec >> already. >> >> Right now I am quite happy with an custom portable extension that does >> everything for me. At the time we implemented the extension we realised >> that the "hard part" was writing an extension that links a qualified >> "optional injection point" with an @Producer method while supporting code >> based default values. Luckily I had Arne in my team who did that within a >> few minutes. >> >> Because of this experience I would propose that we simplify extension >> development such that "optional injection points" may be linked to >> @Produces values easily. Additionally we have to solve a few more >> integration issues (e.g. read-only DB access should be available during CDI >> startup). Everything else should be provided by portable extensions (e.g. >> via delta-spike) and documentation/howtos at cdi-spec.org. >> >> Jens >> [1] >> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >> [2] >> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >> >> Von: Anatole Tresch > >> Datum: Friday 5 September 2014 21:22 >> An: Antonio Goncalves > antonio.goncalves at gmail.com>> >> Cc: CDI-Dev > >> Betreff: Re: [cdi-dev] With the end of Java Config... >> >> Hi all, >> >> I would not like to add an XML "bloated" mechanism as part of CDI 2.0. >> Spontaneously I would propose a more CDI like things like: >> >> >> * Adding a @Configured annotation (basically a qualifier). This can >> be in addition to @Inject and would allow to inject "configured" values. >> * Since configuration can change we may think of a (CDI) >> event/reinject mechanism based on config changes. By default, this is >> switched off and we can discuss how it would be activated, e.g. by an >> additional flag settable with the @Configured annotation, or an additional >> @Observable ConfigChangeEvent (similar to the Griffon framework), or both. >> * Hereby configured values theoretically behave similar as all other >> injection points. They also can be qualified (the aspect of scopes, I did >> not yet have time to think about). The only difference is, that they are >> satisified using the configuration "system". >> * The configuration "source" itself could in the extreme simplest way >> be a Provider>. The CDI spec should not care about how >> this map is provided (XML, DB, overrides, etc). This still can be >> standardized later. As long as the ConfigurationSource SPI is defined, >> companies still can hook in the logic and level of configuration >> abstraction they need. >> * Of course, since not only Strings can be injected, we need some >> conversion or adapter logic as basically outlined in my blog. Also here we >> can add a simple SPI and let the details to the RI. >> >> Summarizing a >> >> * @Configured annotation >> * some kind of change event >> * a ConfigurationSource extends Provider> >> * a conversion mechanism from String to T. >> >> we get a full fledged configuration mechanism that leverages CDI. >> >> That would be my idea basically. WDYT? I will try to work that out in >> more details. Basically it should be implementable even with the CDI >> mechanism already in place with CDI 1.1. >> >> Best, >> Anatole >> >> >> >> >> >> >> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves > >: >> One wise man* once said "EJB was a hype specification, we added too many >> things to it, it became bloated. The next hype specifications are JAX-RS >> and CDI, careful with them" >> >> Either we get this idea of "parts" right, or CDI will endup being bloated. >> >> Antonio >> >> >> *David Blevin >> >> >> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> Hi all, >> >> You may have followed the rise and fall of the Java Config JSR ( >> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >> ). >> Anatole in CC was leading this initiative and I proposed him to join us >> and explore if some part of his late-JSR could be done in CDI. >> >> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >> related solution. If we achieve to have a majority of specs to integrate >> with CDI, our configuration solution would therefore become a configuration >> system for all spec based on CDI 2.0. >> >> 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. >> >> >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter< >> http://twitter.com/agoncal> | LinkedIn >> | Pluralsight< >> http://pluralsight.com/training/Authors/Details/antonio-goncalves> | >> Paris JUG | Devoxx France >> >> _______________________________________________ >> 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. >> >> >> >> -- >> Anatole Tresch >> Java Lead Engineer, JSR Spec Lead >> Gl?rnischweg 10 >> CH - 8620 Wetzikon >> >> Switzerland, Europe Zurich, GMT+1 >> Twitter: @atsticks >> Blogs: http://javaremarkables.blogspot.ch/ >> Google: atsticks >> Mobile +41-76 344 62 79 >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >> *************************************** >> > > > _______________________________________________ > 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. > -- *Anatole Tresch* Java Lead Engineer, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140906/d63993da/attachment-0001.html From john.d.ament at gmail.com Sun Sep 7 08:19:10 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 7 Sep 2014 08:19:10 -0400 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: Message-ID: Anatole, I'm wondering if some of your configuration description falls under what was put together in DeltaSpike? http://deltaspike.apache.org/configuration.html John On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch wrote: > Staging is not a question of xml or not xml (the "format" of config). You > can do staged config also using xml, or based on a database or json config > service. Staging as well as, more generally speaking, environment dependent > config is more like to select/filter the right config that *targets *the > current (runtime) environment. This might include stages, but also many > other aspects are feasible and common (server, tier, ear, war, tenant ...). > Since these aspects are per se very complex, it might be advisable to leave > them out of any spec (even a dedicated config JSR would probably not be > capable of covering these within the relatively short EE timeframe)... > > > 2014-09-05 23:30 GMT+02:00 Werner Keil : > >> Jens/all, >> >> A sort of "staging" already was possible using CDI earlier, see examples >> like this: >> >> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >> >> DeltaSpike also includes type-safe staging that goes beyond the >> primitive, hard-coded JSF enum. >> >> If that works without XML, while still allowing flexible configuration >> for different stages or to add and "inject" additional stages maybe even >> on a tenant basis (for Cloud scenarios) I could see something like that >> work without XML. In the Multiconf project we managed to code everything in >> Python, and similar to Puppet or Chef you can configure and deploy multiple >> environments with it, Java EE, Spring or Play! several of them are >> configured this way and it requires no XML (where the container needs such >> files, the framework generates them;-) >> >> Werner >> >> On Fri, Sep 5, 2014 at 10:21 PM, 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) >>> 2. Re: With the end of Java Config... (Anatole Tresch) >>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>> (Anatole Tresch (JIRA)) >>> 4. Re: With the end of Java Config... (Jens Schumann) >>> >>> ------------------------------ >>> >>> Message: 4 >>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >>> From: Jens Schumann >>> Subject: Re: [cdi-dev] With the end of Java Config... >>> To: Anatole Tresch , Antonio Goncalves >>> >>> Cc: cdi-dev >>> Message-ID: >>> Content-Type: text/plain; charset="windows-1252" >>> >>> I can confirm that this approach works very well. We are using a similar >>> approach a couple of years now, and I love the simplicity that comes with >>> portable extensions and @Producer methods. See our public version here [1] >>> (works since early CDI 1.0 days) . >>> >>> Instead of a @Inject + Qualifier we just use the qualifier @Property. We >>> support default values and type conversation for primitives and everything >>> that has a string based constructor. The property source can be anything, >>> from property files (default) to databases or xml files. For examples see >>> tests here [2]. >>> >>> Nevertheless I am not sure if this should be part of an future CDI spec. >>> My concerns include the bloat argument, of course. But the main reason >>> relates to the fact that we have almost everything in the current CDI spec >>> already. >>> >>> Right now I am quite happy with an custom portable extension that does >>> everything for me. At the time we implemented the extension we realised >>> that the "hard part" was writing an extension that links a qualified >>> "optional injection point" with an @Producer method while supporting code >>> based default values. Luckily I had Arne in my team who did that within a >>> few minutes. >>> >>> Because of this experience I would propose that we simplify extension >>> development such that "optional injection points" may be linked to >>> @Produces values easily. Additionally we have to solve a few more >>> integration issues (e.g. read-only DB access should be available during CDI >>> startup). Everything else should be provided by portable extensions (e.g. >>> via delta-spike) and documentation/howtos at cdi-spec.org. >>> >>> Jens >>> [1] >>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>> [2] >>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>> >>> Von: Anatole Tresch > >>> Datum: Friday 5 September 2014 21:22 >>> An: Antonio Goncalves >> antonio.goncalves at gmail.com>> >>> Cc: CDI-Dev > >>> Betreff: Re: [cdi-dev] With the end of Java Config... >>> >>> Hi all, >>> >>> I would not like to add an XML "bloated" mechanism as part of CDI 2.0. >>> Spontaneously I would propose a more CDI like things like: >>> >>> >>> * Adding a @Configured annotation (basically a qualifier). This can >>> be in addition to @Inject and would allow to inject "configured" values. >>> * Since configuration can change we may think of a (CDI) >>> event/reinject mechanism based on config changes. By default, this is >>> switched off and we can discuss how it would be activated, e.g. by an >>> additional flag settable with the @Configured annotation, or an additional >>> @Observable ConfigChangeEvent (similar to the Griffon framework), or both. >>> * Hereby configured values theoretically behave similar as all other >>> injection points. They also can be qualified (the aspect of scopes, I did >>> not yet have time to think about). The only difference is, that they are >>> satisified using the configuration "system". >>> * The configuration "source" itself could in the extreme simplest >>> way be a Provider>. The CDI spec should not care about >>> how this map is provided (XML, DB, overrides, etc). This still can be >>> standardized later. As long as the ConfigurationSource SPI is defined, >>> companies still can hook in the logic and level of configuration >>> abstraction they need. >>> * Of course, since not only Strings can be injected, we need some >>> conversion or adapter logic as basically outlined in my blog. Also here we >>> can add a simple SPI and let the details to the RI. >>> >>> Summarizing a >>> >>> * @Configured annotation >>> * some kind of change event >>> * a ConfigurationSource extends Provider> >>> * a conversion mechanism from String to T. >>> >>> we get a full fledged configuration mechanism that leverages CDI. >>> >>> That would be my idea basically. WDYT? I will try to work that out in >>> more details. Basically it should be implementable even with the CDI >>> mechanism already in place with CDI 1.1. >>> >>> Best, >>> Anatole >>> >>> >>> >>> >>> >>> >>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves < >>> antonio.goncalves at gmail.com>: >>> One wise man* once said "EJB was a hype specification, we added too many >>> things to it, it became bloated. The next hype specifications are JAX-RS >>> and CDI, careful with them" >>> >>> Either we get this idea of "parts" right, or CDI will endup being >>> bloated. >>> >>> Antonio >>> >>> >>> *David Blevin >>> >>> >>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < >>> antoine at sabot-durand.net> wrote: >>> Hi all, >>> >>> You may have followed the rise and fall of the Java Config JSR ( >>> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >>> ). >>> Anatole in CC was leading this initiative and I proposed him to join us >>> and explore if some part of his late-JSR could be done in CDI. >>> >>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >>> related solution. If we achieve to have a majority of specs to integrate >>> with CDI, our configuration solution would therefore become a configuration >>> system for all spec based on CDI 2.0. >>> >>> 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. >>> >>> >>> >>> -- >>> Antonio Goncalves >>> Software architect, Java Champion and Pluralsight author >>> >>> Web site | Twitter< >>> http://twitter.com/agoncal> | LinkedIn< >>> http://www.linkedin.com/in/agoncal> | Pluralsight< >>> http://pluralsight.com/training/Authors/Details/antonio-goncalves> | >>> Paris JUG | Devoxx France >>> >>> _______________________________________________ >>> 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. >>> >>> >>> >>> -- >>> Anatole Tresch >>> Java Lead Engineer, JSR Spec Lead >>> Gl?rnischweg 10 >>> CH - 8620 Wetzikon >>> >>> Switzerland, Europe Zurich, GMT+1 >>> Twitter: @atsticks >>> Blogs: http://javaremarkables.blogspot.ch/ >>> Google: atsticks >>> Mobile +41-76 344 62 79 >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>> *************************************** >>> >> >> >> _______________________________________________ >> 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. >> > > > > -- > *Anatole Tresch* > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > * > > *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* > > _______________________________________________ > 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/20140907/9775e1ea/attachment-0001.html From werner.keil at gmail.com Sun Sep 7 08:29:14 2014 From: werner.keil at gmail.com (Werner Keil) Date: Sun, 7 Sep 2014 14:29:14 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: Message-ID: Yep, it contains a simple but extendable notion of ProjectStage, too;-) On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament wrote: > Anatole, > > I'm wondering if some of your configuration description falls under what > was put together in DeltaSpike? > > http://deltaspike.apache.org/configuration.html > > John > > > On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch wrote: > >> Staging is not a question of xml or not xml (the "format" of config). You >> can do staged config also using xml, or based on a database or json config >> service. Staging as well as, more generally speaking, environment dependent >> config is more like to select/filter the right config that *targets *the >> current (runtime) environment. This might include stages, but also many >> other aspects are feasible and common (server, tier, ear, war, tenant ...). >> Since these aspects are per se very complex, it might be advisable to leave >> them out of any spec (even a dedicated config JSR would probably not be >> capable of covering these within the relatively short EE timeframe)... >> >> >> 2014-09-05 23:30 GMT+02:00 Werner Keil : >> >>> Jens/all, >>> >>> A sort of "staging" already was possible using CDI earlier, see examples >>> like this: >>> >>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >>> >>> DeltaSpike also includes type-safe staging that goes beyond the >>> primitive, hard-coded JSF enum. >>> >>> If that works without XML, while still allowing flexible configuration >>> for different stages or to add and "inject" additional stages maybe even >>> on a tenant basis (for Cloud scenarios) I could see something like that >>> work without XML. In the Multiconf project we managed to code everything in >>> Python, and similar to Puppet or Chef you can configure and deploy multiple >>> environments with it, Java EE, Spring or Play! several of them are >>> configured this way and it requires no XML (where the container needs such >>> files, the framework generates them;-) >>> >>> Werner >>> >>> On Fri, Sep 5, 2014 at 10:21 PM, >>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) >>>> 2. Re: With the end of Java Config... (Anatole Tresch) >>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>>> (Anatole Tresch (JIRA)) >>>> 4. Re: With the end of Java Config... (Jens Schumann) >>>> >>>> ------------------------------ >>>> >>>> Message: 4 >>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >>>> From: Jens Schumann >>>> Subject: Re: [cdi-dev] With the end of Java Config... >>>> To: Anatole Tresch , Antonio Goncalves >>>> >>>> Cc: cdi-dev >>>> Message-ID: >>>> Content-Type: text/plain; charset="windows-1252" >>>> >>>> I can confirm that this approach works very well. We are using a >>>> similar approach a couple of years now, and I love the simplicity that >>>> comes with portable extensions and @Producer methods. See our public >>>> version here [1] (works since early CDI 1.0 days) . >>>> >>>> Instead of a @Inject + Qualifier we just use the qualifier @Property. >>>> We support default values and type conversation for primitives and >>>> everything that has a string based constructor. The property source can be >>>> anything, from property files (default) to databases or xml files. For >>>> examples see tests here [2]. >>>> >>>> Nevertheless I am not sure if this should be part of an future CDI >>>> spec. My concerns include the bloat argument, of course. But the main >>>> reason relates to the fact that we have almost everything in the current >>>> CDI spec already. >>>> >>>> Right now I am quite happy with an custom portable extension that does >>>> everything for me. At the time we implemented the extension we realised >>>> that the "hard part" was writing an extension that links a qualified >>>> "optional injection point" with an @Producer method while supporting code >>>> based default values. Luckily I had Arne in my team who did that within a >>>> few minutes. >>>> >>>> Because of this experience I would propose that we simplify extension >>>> development such that "optional injection points" may be linked to >>>> @Produces values easily. Additionally we have to solve a few more >>>> integration issues (e.g. read-only DB access should be available during CDI >>>> startup). Everything else should be provided by portable extensions (e.g. >>>> via delta-spike) and documentation/howtos at cdi-spec.org. >>>> >>>> Jens >>>> [1] >>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>>> [2] >>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>>> >>>> Von: Anatole Tresch > >>>> Datum: Friday 5 September 2014 21:22 >>>> An: Antonio Goncalves >>> antonio.goncalves at gmail.com>> >>>> Cc: CDI-Dev > >>>> Betreff: Re: [cdi-dev] With the end of Java Config... >>>> >>>> Hi all, >>>> >>>> I would not like to add an XML "bloated" mechanism as part of CDI 2.0. >>>> Spontaneously I would propose a more CDI like things like: >>>> >>>> >>>> * Adding a @Configured annotation (basically a qualifier). This can >>>> be in addition to @Inject and would allow to inject "configured" values. >>>> * Since configuration can change we may think of a (CDI) >>>> event/reinject mechanism based on config changes. By default, this is >>>> switched off and we can discuss how it would be activated, e.g. by an >>>> additional flag settable with the @Configured annotation, or an additional >>>> @Observable ConfigChangeEvent (similar to the Griffon framework), or both. >>>> * Hereby configured values theoretically behave similar as all >>>> other injection points. They also can be qualified (the aspect of scopes, I >>>> did not yet have time to think about). The only difference is, that they >>>> are satisified using the configuration "system". >>>> * The configuration "source" itself could in the extreme simplest >>>> way be a Provider>. The CDI spec should not care about >>>> how this map is provided (XML, DB, overrides, etc). This still can be >>>> standardized later. As long as the ConfigurationSource SPI is defined, >>>> companies still can hook in the logic and level of configuration >>>> abstraction they need. >>>> * Of course, since not only Strings can be injected, we need some >>>> conversion or adapter logic as basically outlined in my blog. Also here we >>>> can add a simple SPI and let the details to the RI. >>>> >>>> Summarizing a >>>> >>>> * @Configured annotation >>>> * some kind of change event >>>> * a ConfigurationSource extends Provider> >>>> * a conversion mechanism from String to T. >>>> >>>> we get a full fledged configuration mechanism that leverages CDI. >>>> >>>> That would be my idea basically. WDYT? I will try to work that out in >>>> more details. Basically it should be implementable even with the CDI >>>> mechanism already in place with CDI 1.1. >>>> >>>> Best, >>>> Anatole >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves < >>>> antonio.goncalves at gmail.com>: >>>> One wise man* once said "EJB was a hype specification, we added too >>>> many things to it, it became bloated. The next hype specifications are >>>> JAX-RS and CDI, careful with them" >>>> >>>> Either we get this idea of "parts" right, or CDI will endup being >>>> bloated. >>>> >>>> Antonio >>>> >>>> >>>> *David Blevin >>>> >>>> >>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < >>>> antoine at sabot-durand.net> wrote: >>>> Hi all, >>>> >>>> You may have followed the rise and fall of the Java Config JSR ( >>>> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >>>> ). >>>> Anatole in CC was leading this initiative and I proposed him to join us >>>> and explore if some part of his late-JSR could be done in CDI. >>>> >>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >>>> related solution. If we achieve to have a majority of specs to integrate >>>> with CDI, our configuration solution would therefore become a configuration >>>> system for all spec based on CDI 2.0. >>>> >>>> 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. >>>> >>>> >>>> >>>> -- >>>> Antonio Goncalves >>>> Software architect, Java Champion and Pluralsight author >>>> >>>> Web site | Twitter< >>>> http://twitter.com/agoncal> | LinkedIn< >>>> http://www.linkedin.com/in/agoncal> | Pluralsight< >>>> http://pluralsight.com/training/Authors/Details/antonio-goncalves> | >>>> Paris JUG | Devoxx France>>> > >>>> >>>> _______________________________________________ >>>> 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. >>>> >>>> >>>> >>>> -- >>>> Anatole Tresch >>>> Java Lead Engineer, JSR Spec Lead >>>> Gl?rnischweg 10 >>>> CH - 8620 Wetzikon >>>> >>>> Switzerland, Europe Zurich, GMT+1 >>>> Twitter: @atsticks >>>> Blogs: http://javaremarkables.blogspot.ch/ >>>> Google: atsticks >>>> Mobile +41-76 344 62 79 >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: >>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>>> *************************************** >>>> >>> >>> >>> _______________________________________________ >>> 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. >>> >> >> >> >> -- >> *Anatole Tresch* >> Java Lead Engineer, JSR Spec Lead >> Gl?rnischweg 10 >> CH - 8620 Wetzikon >> >> *Switzerland, Europe Zurich, GMT+1* >> *Twitter: @atsticks* >> *Blogs: **http://javaremarkables.blogspot.ch/ >> * >> >> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* >> >> _______________________________________________ >> 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/20140907/37267d8d/attachment-0001.html From john.d.ament at gmail.com Sun Sep 7 08:31:40 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 7 Sep 2014 08:31:40 -0400 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: Message-ID: Yeah... personally, I dislike project stage. I for one would be hung out to dry if I ever mixed my dev/test/prd environment configs in one file. Much more, my devops would treat me like a pinata if I told them the configuration keys were different in each environment... :-) On Sun, Sep 7, 2014 at 8:29 AM, Werner Keil wrote: > Yep, it contains a simple but extendable notion of ProjectStage, too;-) > > > > On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament > wrote: > >> Anatole, >> >> I'm wondering if some of your configuration description falls under what >> was put together in DeltaSpike? >> >> http://deltaspike.apache.org/configuration.html >> >> John >> >> >> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch >> wrote: >> >>> Staging is not a question of xml or not xml (the "format" of config). >>> You can do staged config also using xml, or based on a database or json >>> config service. Staging as well as, more generally speaking, environment >>> dependent config is more like to select/filter the right config that >>> *targets *the current (runtime) environment. This might include stages, >>> but also many other aspects are feasible and common (server, tier, ear, >>> war, tenant ...). Since these aspects are per se very complex, it might be >>> advisable to leave them out of any spec (even a dedicated config JSR would >>> probably not be capable of covering these within the relatively short EE >>> timeframe)... >>> >>> >>> 2014-09-05 23:30 GMT+02:00 Werner Keil : >>> >>>> Jens/all, >>>> >>>> A sort of "staging" already was possible using CDI earlier, see >>>> examples like this: >>>> >>>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >>>> >>>> DeltaSpike also includes type-safe staging that goes beyond the >>>> primitive, hard-coded JSF enum. >>>> >>>> If that works without XML, while still allowing flexible configuration >>>> for different stages or to add and "inject" additional stages maybe even >>>> on a tenant basis (for Cloud scenarios) I could see something like that >>>> work without XML. In the Multiconf project we managed to code everything in >>>> Python, and similar to Puppet or Chef you can configure and deploy multiple >>>> environments with it, Java EE, Spring or Play! several of them are >>>> configured this way and it requires no XML (where the container needs such >>>> files, the framework generates them;-) >>>> >>>> Werner >>>> >>>> On Fri, Sep 5, 2014 at 10:21 PM, >>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) >>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>>>> (Anatole Tresch (JIRA)) >>>>> 4. Re: With the end of Java Config... (Jens Schumann) >>>>> >>>>> ------------------------------ >>>>> >>>>> Message: 4 >>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >>>>> From: Jens Schumann >>>>> Subject: Re: [cdi-dev] With the end of Java Config... >>>>> To: Anatole Tresch , Antonio Goncalves >>>>> >>>>> Cc: cdi-dev >>>>> Message-ID: >>>>> Content-Type: text/plain; charset="windows-1252" >>>>> >>>>> I can confirm that this approach works very well. We are using a >>>>> similar approach a couple of years now, and I love the simplicity that >>>>> comes with portable extensions and @Producer methods. See our public >>>>> version here [1] (works since early CDI 1.0 days) . >>>>> >>>>> Instead of a @Inject + Qualifier we just use the qualifier @Property. >>>>> We support default values and type conversation for primitives and >>>>> everything that has a string based constructor. The property source can be >>>>> anything, from property files (default) to databases or xml files. For >>>>> examples see tests here [2]. >>>>> >>>>> Nevertheless I am not sure if this should be part of an future CDI >>>>> spec. My concerns include the bloat argument, of course. But the main >>>>> reason relates to the fact that we have almost everything in the current >>>>> CDI spec already. >>>>> >>>>> Right now I am quite happy with an custom portable extension that does >>>>> everything for me. At the time we implemented the extension we realised >>>>> that the "hard part" was writing an extension that links a qualified >>>>> "optional injection point" with an @Producer method while supporting code >>>>> based default values. Luckily I had Arne in my team who did that within a >>>>> few minutes. >>>>> >>>>> Because of this experience I would propose that we simplify extension >>>>> development such that "optional injection points" may be linked to >>>>> @Produces values easily. Additionally we have to solve a few more >>>>> integration issues (e.g. read-only DB access should be available during CDI >>>>> startup). Everything else should be provided by portable extensions (e.g. >>>>> via delta-spike) and documentation/howtos at cdi-spec.org. >>>>> >>>>> Jens >>>>> [1] >>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>>>> [2] >>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>>>> >>>>> Von: Anatole Tresch > >>>>> Datum: Friday 5 September 2014 21:22 >>>>> An: Antonio Goncalves >>>> antonio.goncalves at gmail.com>> >>>>> Cc: CDI-Dev > >>>>> Betreff: Re: [cdi-dev] With the end of Java Config... >>>>> >>>>> Hi all, >>>>> >>>>> I would not like to add an XML "bloated" mechanism as part of CDI 2.0. >>>>> Spontaneously I would propose a more CDI like things like: >>>>> >>>>> >>>>> * Adding a @Configured annotation (basically a qualifier). This >>>>> can be in addition to @Inject and would allow to inject "configured" values. >>>>> * Since configuration can change we may think of a (CDI) >>>>> event/reinject mechanism based on config changes. By default, this is >>>>> switched off and we can discuss how it would be activated, e.g. by an >>>>> additional flag settable with the @Configured annotation, or an additional >>>>> @Observable ConfigChangeEvent (similar to the Griffon framework), or both. >>>>> * Hereby configured values theoretically behave similar as all >>>>> other injection points. They also can be qualified (the aspect of scopes, I >>>>> did not yet have time to think about). The only difference is, that they >>>>> are satisified using the configuration "system". >>>>> * The configuration "source" itself could in the extreme simplest >>>>> way be a Provider>. The CDI spec should not care about >>>>> how this map is provided (XML, DB, overrides, etc). This still can be >>>>> standardized later. As long as the ConfigurationSource SPI is defined, >>>>> companies still can hook in the logic and level of configuration >>>>> abstraction they need. >>>>> * Of course, since not only Strings can be injected, we need some >>>>> conversion or adapter logic as basically outlined in my blog. Also here we >>>>> can add a simple SPI and let the details to the RI. >>>>> >>>>> Summarizing a >>>>> >>>>> * @Configured annotation >>>>> * some kind of change event >>>>> * a ConfigurationSource extends Provider> >>>>> * a conversion mechanism from String to T. >>>>> >>>>> we get a full fledged configuration mechanism that leverages CDI. >>>>> >>>>> That would be my idea basically. WDYT? I will try to work that out in >>>>> more details. Basically it should be implementable even with the CDI >>>>> mechanism already in place with CDI 1.1. >>>>> >>>>> Best, >>>>> Anatole >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves < >>>>> antonio.goncalves at gmail.com>: >>>>> One wise man* once said "EJB was a hype specification, we added too >>>>> many things to it, it became bloated. The next hype specifications are >>>>> JAX-RS and CDI, careful with them" >>>>> >>>>> Either we get this idea of "parts" right, or CDI will endup being >>>>> bloated. >>>>> >>>>> Antonio >>>>> >>>>> >>>>> *David Blevin >>>>> >>>>> >>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < >>>>> antoine at sabot-durand.net> wrote: >>>>> Hi all, >>>>> >>>>> You may have followed the rise and fall of the Java Config JSR ( >>>>> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >>>>> ). >>>>> Anatole in CC was leading this initiative and I proposed him to join >>>>> us and explore if some part of his late-JSR could be done in CDI. >>>>> >>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >>>>> related solution. If we achieve to have a majority of specs to integrate >>>>> with CDI, our configuration solution would therefore become a configuration >>>>> system for all spec based on CDI 2.0. >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> -- >>>>> Antonio Goncalves >>>>> Software architect, Java Champion and Pluralsight author >>>>> >>>>> Web site | Twitter< >>>>> http://twitter.com/agoncal> | LinkedIn< >>>>> http://www.linkedin.com/in/agoncal> | Pluralsight< >>>>> http://pluralsight.com/training/Authors/Details/antonio-goncalves> | >>>>> Paris JUG | Devoxx France< >>>>> http://www.devoxx.fr> >>>>> >>>>> _______________________________________________ >>>>> 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. >>>>> >>>>> >>>>> >>>>> -- >>>>> Anatole Tresch >>>>> Java Lead Engineer, JSR Spec Lead >>>>> Gl?rnischweg 10 >>>>> CH - 8620 Wetzikon >>>>> >>>>> Switzerland, Europe Zurich, GMT+1 >>>>> Twitter: @atsticks >>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>>> Google: atsticks >>>>> Mobile +41-76 344 62 79 >>>>> -------------- next part -------------- >>>>> An HTML attachment was scrubbed... >>>>> URL: >>>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>>>> *************************************** >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. >>>> >>> >>> >>> >>> -- >>> *Anatole Tresch* >>> Java Lead Engineer, JSR Spec Lead >>> Gl?rnischweg 10 >>> CH - 8620 Wetzikon >>> >>> *Switzerland, Europe Zurich, GMT+1* >>> *Twitter: @atsticks* >>> *Blogs: **http://javaremarkables.blogspot.ch/ >>> * >>> >>> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* >>> >>> _______________________________________________ >>> 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/20140907/f2edae8c/attachment-0001.html From werner.keil at gmail.com Sun Sep 7 08:41:37 2014 From: werner.keil at gmail.com (Werner Keil) Date: Sun, 7 Sep 2014 14:41:37 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: Message-ID: Maybe not all keys, but VALUES are, if you ever worked in a true Cloud or DevOps environment?;-) That's exactly what we did e.g. with the Multiconf DevOps framework: https://github.com/lhupfeldt/multiconf While written in Python, it allowed Java EE aps (on more than just one container, JBoss, WLS, Play it covers all;-) to handle multiple stages and configuration. This way doing so on a (continuous) delivery level, a JAR, WAR or similar artifact and all config data are tailor-made for a stage, I believe, from what Anatole mentioned, this could also be sort of Oracle's preference for config management in Java (sort of helping Maven, Ant, Gradle or CI tools like Multiconf;-) but DeltaSpike and other config solutions including Spring Config usually do this at runtime, too. Without the need of a JAR per stage or tenant, it adapts and knows where it's running;-) I saw many (Outsourcing) providers we helped with these things and some indeed used something like - LOG_FOLDER_ON_DEV - LOG_FOLDER_ON_UAT - LOG_FOLDER_ON_PROD (you get the idea;-) that is not what DeltaSpike config proposes and neither does Spring in most cases. Werner On Sun, Sep 7, 2014 at 2:31 PM, John D. Ament wrote: > Yeah... personally, I dislike project stage. I for one would be hung out > to dry if I ever mixed my dev/test/prd environment configs in one file. > Much more, my devops would treat me like a pinata if I told them the > configuration keys were different in each environment... :-) > > > On Sun, Sep 7, 2014 at 8:29 AM, Werner Keil wrote: > >> Yep, it contains a simple but extendable notion of ProjectStage, too;-) >> >> >> >> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament >> wrote: >> >>> Anatole, >>> >>> I'm wondering if some of your configuration description falls under what >>> was put together in DeltaSpike? >>> >>> http://deltaspike.apache.org/configuration.html >>> >>> John >>> >>> >>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch >>> wrote: >>> >>>> Staging is not a question of xml or not xml (the "format" of config). >>>> You can do staged config also using xml, or based on a database or json >>>> config service. Staging as well as, more generally speaking, environment >>>> dependent config is more like to select/filter the right config that >>>> *targets *the current (runtime) environment. This might include >>>> stages, but also many other aspects are feasible and common (server, tier, >>>> ear, war, tenant ...). Since these aspects are per se very complex, it >>>> might be advisable to leave them out of any spec (even a dedicated config >>>> JSR would probably not be capable of covering these within the relatively >>>> short EE timeframe)... >>>> >>>> >>>> 2014-09-05 23:30 GMT+02:00 Werner Keil : >>>> >>>>> Jens/all, >>>>> >>>>> A sort of "staging" already was possible using CDI earlier, see >>>>> examples like this: >>>>> >>>>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >>>>> >>>>> DeltaSpike also includes type-safe staging that goes beyond the >>>>> primitive, hard-coded JSF enum. >>>>> >>>>> If that works without XML, while still allowing flexible configuration >>>>> for different stages or to add and "inject" additional stages maybe even >>>>> on a tenant basis (for Cloud scenarios) I could see something like that >>>>> work without XML. In the Multiconf project we managed to code everything in >>>>> Python, and similar to Puppet or Chef you can configure and deploy multiple >>>>> environments with it, Java EE, Spring or Play! several of them are >>>>> configured this way and it requires no XML (where the container needs such >>>>> files, the framework generates them;-) >>>>> >>>>> Werner >>>>> >>>>> On Fri, Sep 5, 2014 at 10:21 PM, >>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>>>>> (Anatole Tresch (JIRA)) >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) >>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> Message: 4 >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >>>>>> From: Jens Schumann >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... >>>>>> To: Anatole Tresch , Antonio Goncalves >>>>>> >>>>>> Cc: cdi-dev >>>>>> Message-ID: >>>>>> Content-Type: text/plain; charset="windows-1252" >>>>>> >>>>>> I can confirm that this approach works very well. We are using a >>>>>> similar approach a couple of years now, and I love the simplicity that >>>>>> comes with portable extensions and @Producer methods. See our public >>>>>> version here [1] (works since early CDI 1.0 days) . >>>>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier @Property. >>>>>> We support default values and type conversation for primitives and >>>>>> everything that has a string based constructor. The property source can be >>>>>> anything, from property files (default) to databases or xml files. For >>>>>> examples see tests here [2]. >>>>>> >>>>>> Nevertheless I am not sure if this should be part of an future CDI >>>>>> spec. My concerns include the bloat argument, of course. But the main >>>>>> reason relates to the fact that we have almost everything in the current >>>>>> CDI spec already. >>>>>> >>>>>> Right now I am quite happy with an custom portable extension that >>>>>> does everything for me. At the time we implemented the extension we >>>>>> realised that the "hard part" was writing an extension that links a >>>>>> qualified "optional injection point" with an @Producer method while >>>>>> supporting code based default values. Luckily I had Arne in my team who did >>>>>> that within a few minutes. >>>>>> >>>>>> Because of this experience I would propose that we simplify extension >>>>>> development such that "optional injection points" may be linked to >>>>>> @Produces values easily. Additionally we have to solve a few more >>>>>> integration issues (e.g. read-only DB access should be available during CDI >>>>>> startup). Everything else should be provided by portable extensions (e.g. >>>>>> via delta-spike) and documentation/howtos at cdi-spec.org. >>>>>> >>>>>> Jens >>>>>> [1] >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>>>>> [2] >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>>>>> >>>>>> Von: Anatole Tresch > >>>>>> Datum: Friday 5 September 2014 21:22 >>>>>> An: Antonio Goncalves >>>>> antonio.goncalves at gmail.com>> >>>>>> Cc: CDI-Dev > >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I would not like to add an XML "bloated" mechanism as part of CDI >>>>>> 2.0. Spontaneously I would propose a more CDI like things like: >>>>>> >>>>>> >>>>>> * Adding a @Configured annotation (basically a qualifier). This >>>>>> can be in addition to @Inject and would allow to inject "configured" values. >>>>>> * Since configuration can change we may think of a (CDI) >>>>>> event/reinject mechanism based on config changes. By default, this is >>>>>> switched off and we can discuss how it would be activated, e.g. by an >>>>>> additional flag settable with the @Configured annotation, or an additional >>>>>> @Observable ConfigChangeEvent (similar to the Griffon framework), or both. >>>>>> * Hereby configured values theoretically behave similar as all >>>>>> other injection points. They also can be qualified (the aspect of scopes, I >>>>>> did not yet have time to think about). The only difference is, that they >>>>>> are satisified using the configuration "system". >>>>>> * The configuration "source" itself could in the extreme simplest >>>>>> way be a Provider>. The CDI spec should not care about >>>>>> how this map is provided (XML, DB, overrides, etc). This still can be >>>>>> standardized later. As long as the ConfigurationSource SPI is defined, >>>>>> companies still can hook in the logic and level of configuration >>>>>> abstraction they need. >>>>>> * Of course, since not only Strings can be injected, we need some >>>>>> conversion or adapter logic as basically outlined in my blog. Also here we >>>>>> can add a simple SPI and let the details to the RI. >>>>>> >>>>>> Summarizing a >>>>>> >>>>>> * @Configured annotation >>>>>> * some kind of change event >>>>>> * a ConfigurationSource extends Provider> >>>>>> * a conversion mechanism from String to T. >>>>>> >>>>>> we get a full fledged configuration mechanism that leverages CDI. >>>>>> >>>>>> That would be my idea basically. WDYT? I will try to work that out in >>>>>> more details. Basically it should be implementable even with the CDI >>>>>> mechanism already in place with CDI 1.1. >>>>>> >>>>>> Best, >>>>>> Anatole >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves < >>>>>> antonio.goncalves at gmail.com>: >>>>>> One wise man* once said "EJB was a hype specification, we added too >>>>>> many things to it, it became bloated. The next hype specifications are >>>>>> JAX-RS and CDI, careful with them" >>>>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup being >>>>>> bloated. >>>>>> >>>>>> Antonio >>>>>> >>>>>> >>>>>> *David Blevin >>>>>> >>>>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < >>>>>> antoine at sabot-durand.net> wrote: >>>>>> Hi all, >>>>>> >>>>>> You may have followed the rise and fall of the Java Config JSR ( >>>>>> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >>>>>> ). >>>>>> Anatole in CC was leading this initiative and I proposed him to join >>>>>> us and explore if some part of his late-JSR could be done in CDI. >>>>>> >>>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >>>>>> related solution. If we achieve to have a majority of specs to integrate >>>>>> with CDI, our configuration solution would therefore become a configuration >>>>>> system for all spec based on CDI 2.0. >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Antonio Goncalves >>>>>> Software architect, Java Champion and Pluralsight author >>>>>> >>>>>> Web site | Twitter< >>>>>> http://twitter.com/agoncal> | LinkedIn< >>>>>> http://www.linkedin.com/in/agoncal> | Pluralsight< >>>>>> http://pluralsight.com/training/Authors/Details/antonio-goncalves> | >>>>>> Paris JUG | Devoxx France< >>>>>> http://www.devoxx.fr> >>>>>> >>>>>> _______________________________________________ >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Anatole Tresch >>>>>> Java Lead Engineer, JSR Spec Lead >>>>>> Gl?rnischweg 10 >>>>>> CH - 8620 Wetzikon >>>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>>>>> Twitter: @atsticks >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>>>> Google: atsticks >>>>>> Mobile +41-76 344 62 79 >>>>>> -------------- next part -------------- >>>>>> An HTML attachment was scrubbed... >>>>>> URL: >>>>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>>>>> *************************************** >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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. >>>>> >>>> >>>> >>>> >>>> -- >>>> *Anatole Tresch* >>>> Java Lead Engineer, JSR Spec Lead >>>> Gl?rnischweg 10 >>>> CH - 8620 Wetzikon >>>> >>>> *Switzerland, Europe Zurich, GMT+1* >>>> *Twitter: @atsticks* >>>> *Blogs: **http://javaremarkables.blogspot.ch/ >>>> * >>>> >>>> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* >>>> >>>> _______________________________________________ >>>> 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/20140907/99c2ac33/attachment-0001.html From issues at jboss.org Sun Sep 7 08:43:00 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 7 Sep 2014 08:43:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Add a disposable interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999669#comment-12999669 ] John Ament commented on CDI-457: -------------------------------- {code}Instance.destroy(){code} is probably the closest to what I'm looking for, but less error prone. There were a few ways I was thinking to solve this, first is {code} @Produces @UnManaged public SomeClass produceSomeClass() {... {code} @UnManaged would be a new annotation indicating that the returned object is not contextual (and hence, implicitly dependent). Another way, using the Instance<> approach would be: {code} Disposable dsc = CDI.current().select(SomeClass.class).getDisposable(); try(SomeClass sc = dsc.get()) { // do something with some class } {code} so that when the Disposable object goes out of scope, it gets cleaned up. > Add a disposable interface > -------------------------- > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed. > I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From struberg at yahoo.de Sun Sep 7 08:46:44 2014 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 7 Sep 2014 13:46:44 +0100 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: Message-ID: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Yes, the config group also was (obviously) looking at DeltaSpikes config mechanism as well. There were others who wanted to go more into the 'filtering' approach as done on WebLogic servers (though not sure who else does that as well). You know, having all the XML configs like WEB-INF/web.xml containing placeholders and the real values only get placed in there at deployment time. I personally find this approach a bit limited from a technical perspective and it already didn't work out for me when using WebLogic (what about changing a configured value after the deployment was done? What about security? Having passwords in web.xml, unit testing, ...). There are of course also other approaches which all might have strong sides and would have needed to get discussed. But utterly the problem seems to have been legal reasons. We even offered to have Anatole/CS lead the EG and do the RI as an ASF project with substantial support and participation from the JBoss, DeltaSpike and TomEE communities. Anyway, the time will come when we will resurrect this effort. LieGrue, strub On Sunday, 7 September 2014, 14:29, Werner Keil wrote: > > >Yep, it contains a simple but extendable notion of ProjectStage, too;-) > > > >On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament wrote: > >Anatole, >> >> >>I'm wondering if some of your configuration description falls under what was put together in DeltaSpike? >> >> >>http://deltaspike.apache.org/configuration.html >> >> >> >>John >> >> >> >>On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch wrote: >> >>Staging is not a question of xml or not xml (the "format" of config). You can do staged config also using xml, or based on a database or json config service. Staging as well as, more generally speaking, environment dependent config is more like to select/filter the right config that targets the current (runtime) environment. This might include stages, but also many other aspects are feasible and common (server, tier, ear, war, tenant ...). Since these aspects are per se very complex, it might be advisable to leave them out of any spec (even a dedicated config JSR would probably not be capable of covering these within the relatively short EE timeframe)... >>> >>> >>> >>> >>>2014-09-05 23:30 GMT+02:00 Werner Keil : >>> >>>Jens/all, >>>> >>>> >>>>A sort of "staging" already was possible using CDI earlier, see examples like this: >>>>http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >>>> >>>> >>>>DeltaSpike also includes type-safe staging that goes beyond the primitive, hard-coded JSF enum. >>>> >>>> >>>>If that works without XML, while still allowing flexible configuration for different stages or to add and "inject" additional stages maybe even on a tenant basis (for Cloud scenarios) I could see something like that work without XML. In the Multiconf project we managed to code everything in Python, and similar to Puppet or Chef you can configure and deploy multiple environments with it, Java EE, Spring or Play! several of them are configured this way and it requires no XML (where the container needs such files, the framework generates them;-) >>>> >>>> >>>>Werner >>>> >>>> >>>>On Fri, Sep 5, 2014 at 10:21 PM, 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) >>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>>>> (Anatole Tresch (JIRA)) >>>>> 4. Re: With the end of Java Config... (Jens Schumann) >>>>> >>>>>------------------------------ >>>>> >>>>>Message: 4 >>>>>Date: Fri, 5 Sep 2014 20:20:53 +0000 >>>>>From: Jens Schumann >>>>>Subject: Re: [cdi-dev] With the end of Java Config... >>>>>To: Anatole Tresch , Antonio Goncalves >>>>> >>>>>Cc: cdi-dev >>>>>Message-ID: >>>>>Content-Type: text/plain; charset="windows-1252" >>>>> >>>>>I can confirm that this approach works very well. We are using a similar approach a couple of years now, and I love the simplicity that comes with portable extensions and @Producer methods. See our public version here [1] (works since early CDI 1.0 days) . >>>>> >>>>>Instead of a @Inject + Qualifier we just use the qualifier @Property. We support default values and type conversation for primitives and everything that has a string based constructor. The property source can be anything, from property files (default) to databases or xml files. For examples see tests here [2]. >>>>> >>>>>Nevertheless I am not sure if this should be part of an future CDI spec. My concerns include the bloat argument, of course. But the main reason relates to the fact that we have almost everything in the current CDI spec already. >>>>> >>>>>Right now I am quite happy with an custom portable extension that does everything for me. At the time we implemented the extension we realised that the "hard part" was writing an extension that links a qualified "optional injection point" with an @Producer method while supporting code based default values. Luckily I had Arne in my team who did that within a few minutes. >>>>> >>>>>Because of this experience I would propose that we simplify extension development such that "optional injection points" may be linked to @Produces values easily. Additionally we have to solve a few more integration issues (e.g. read-only DB access should be available during CDI startup). Everything else should be provided by portable extensions (e.g. via delta-spike) and documentation/howtos at cdi-spec.org. >>>>> >>>>>Jens >>>>>[1] https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>>>>[2] https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>>>> >>>>> Von: Anatole Tresch > >>>>>Datum: Friday 5 September 2014 21:22 >>>>> An: Antonio Goncalves > >>>>>Cc: CDI-Dev > >>>>>Betreff: Re: [cdi-dev] With the end of Java Config... >>>>> >>>>>Hi all, >>>>> >>>>>I would not like to add an XML "bloated" mechanism as part of CDI 2.0. Spontaneously I would propose a more CDI like things like: >>>>> >>>>> >>>>> * Adding a @Configured annotation (basically a qualifier). This can be in addition to @Inject and would allow to inject "configured" values. >>>>> * Since configuration can change we may think of a (CDI) event/reinject mechanism based on config changes. By default, this is switched off and we can discuss how it would be activated, e.g. by an additional flag settable with the @Configured annotation, or an additional @Observable ConfigChangeEvent (similar to the Griffon framework), or both. >>>>> * Hereby configured values theoretically behave similar as all other injection points. They also can be qualified (the aspect of scopes, I did not yet have time to think about). The only difference is, that they are satisified using the configuration "system". >>>>> * The configuration "source" itself could in the extreme simplest way be a Provider>. The CDI spec should not care about how this map is provided (XML, DB, overrides, etc). This still can be standardized later. As long as the ConfigurationSource SPI is defined, companies still can hook in the logic and level of configuration abstraction they need. >>>>> * Of course, since not only Strings can be injected, we need some conversion or adapter logic as basically outlined in my blog. Also here we can add a simple SPI and let the details to the RI. >>>>> >>>>>Summarizing a >>>>> >>>>> * @Configured annotation >>>>> * some kind of change event >>>>> * a ConfigurationSource extends Provider> >>>>> * a conversion mechanism from String to T. >>>>> >>>>>we get a full fledged configuration mechanism that leverages CDI. >>>>> >>>>>That would be my idea basically. WDYT? I will try to work that out in more details. Basically it should be implementable even with the CDI mechanism already in place with CDI 1.1. >>>>> >>>>>Best, >>>>>Anatole >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >: >>>>>One wise man* once said "EJB was a hype specification, we added too many things to it, it became bloated. The next hype specifications are JAX-RS and CDI, careful with them" >>>>> >>>>>Either we get this idea of "parts" right, or CDI will endup being bloated. >>>>> >>>>>Antonio >>>>> >>>>> >>>>>*David Blevin >>>>> >>>>> >>>>>On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand > wrote: >>>>>Hi all, >>>>> >>>>>You may have followed the rise and fall of the Java Config JSR (http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html). >>>>>Anatole in CC was leading this initiative and I proposed him to join us and explore if some part of his late-JSR could be done in CDI. >>>>> >>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or related solution. If we achieve to have a majority of specs to integrate with CDI, our configuration solution would therefore become a configuration system for all spec based on CDI 2.0. >>>>> >>>>>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. >>>>> >>>>> >>>>> >>>>>-- >>>>>Antonio Goncalves >>>>>Software architect, Java Champion and Pluralsight author >>>>> >>>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >>>>> >>>>>_______________________________________________ >>>>>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. >>>>> >>>>> >>>>> >>>>>-- >>>>>Anatole Tresch >>>>>Java Lead Engineer, JSR Spec Lead >>>>> Gl?rnischweg 10 >>>>>CH - 8620 Wetzikon >>>>> >>>>>Switzerland, Europe Zurich, GMT+1 >>>>>Twitter: @atsticks >>>>>Blogs: http://javaremarkables.blogspot.ch/ >>>>>Google: atsticks >>>>>Mobile +41-76 344 62 79 >>>>>-------------- next part -------------- >>>>>An HTML attachment was scrubbed... >>>>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>>>>*************************************** >>>>> >>>> >>>>_______________________________________________ >>>>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. >>>> >>> >>> >>> >>>-- >>> >>>Anatole Tresch >>>Java Lead Engineer, JSR Spec Lead >>>Gl?rnischweg 10 >>>CH - 8620 Wetzikon >>> >>> >>>Switzerland, Europe Zurich, GMT+1 >>>Twitter: @atsticks >>>Blogs: http://javaremarkables.blogspot.ch/ >>>Google: atsticks >>>Mobile +41-76 344 62 79 >>>_______________________________________________ >>>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/20140907/4e607e6b/attachment-0001.html From issues at jboss.org Sun Sep 7 08:46:59 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 7 Sep 2014 08:46:59 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Add a disposable interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999670#comment-12999670 ] John Ament commented on CDI-457: -------------------------------- BTW, @TransientReference would work in the producer method solution, if it were allowed on methods/fields, rather than params only. WDYT about allowing @TransientReference on producer methods? Allowing the producer to control the behavior of the injected reference, rather than the injection point controlling it? > Add a disposable interface > -------------------------- > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed. > I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From werner.keil at gmail.com Sun Sep 7 08:51:00 2014 From: werner.keil at gmail.com (Werner Keil) Date: Sun, 7 Sep 2014 14:51:00 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: P.s.: There's a new Servlet JSR (369) also proposed with supporters everywhere from Google to Red Hat or Pivotal. As I missed it a bit earlier, note, Servlet also has its own config sub-system: http://www.java4s.com/java-servlet-tutorials/example-of-servletconfig-in-java-servlet/ This interface was around ever since Servlet 1.0 I recall and it certainly won't go away in 4.0 but a proper introduction of a (CDI or separate) config mechanism would also have to say try offer a bit of improvement there. That's what JSR 369 seems about after all;-) Werner On Sun, Sep 7, 2014 at 2:46 PM, Mark Struberg wrote: > Yes, the config group also was (obviously) looking at DeltaSpikes config > mechanism as well. > There were others who wanted to go more into the 'filtering' approach as > done on WebLogic servers (though not sure who else does that as well). > You know, having all the XML configs like WEB-INF/web.xml containing > placeholders and the real values only get placed in there at deployment > time. I personally find this approach a bit limited from a technical > perspective and it already didn't work out for me when using WebLogic (what > about changing a configured value after the deployment was done? What about > security? Having passwords in web.xml, unit testing, ...). > There are of course also other approaches which all might have strong > sides and would have needed to get discussed. > > But utterly the problem seems to have been legal reasons. We even offered > to have Anatole/CS lead the EG and do the RI as an ASF project with > substantial support and participation from the JBoss, DeltaSpike and TomEE > communities. > > Anyway, the time will come when we will resurrect this effort. > > LieGrue, > strub > > > > > On Sunday, 7 September 2014, 14:29, Werner Keil > wrote: > > > > Yep, it contains a simple but extendable notion of ProjectStage, too;-) > > > On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament > wrote: > > Anatole, > > I'm wondering if some of your configuration description falls under what > was put together in DeltaSpike? > > http://deltaspike.apache.org/configuration.html > > John > > > On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch wrote: > > Staging is not a question of xml or not xml (the "format" of config). You > can do staged config also using xml, or based on a database or json config > service. Staging as well as, more generally speaking, environment dependent > config is more like to select/filter the right config that *targets *the > current (runtime) environment. This might include stages, but also many > other aspects are feasible and common (server, tier, ear, war, tenant ...). > Since these aspects are per se very complex, it might be advisable to leave > them out of any spec (even a dedicated config JSR would probably not be > capable of covering these within the relatively short EE timeframe)... > > > 2014-09-05 23:30 GMT+02:00 Werner Keil : > > Jens/all, > > A sort of "staging" already was possible using CDI earlier, see examples > like this: > > http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war > > DeltaSpike also includes type-safe staging that goes beyond the primitive, > hard-coded JSF enum. > > If that works without XML, while still allowing flexible configuration for > different stages or to add and "inject" additional stages maybe even on a > tenant basis (for Cloud scenarios) I could see something like that work > without XML. In the Multiconf project we managed to code everything in > Python, and similar to Puppet or Chef you can configure and deploy multiple > environments with it, Java EE, Spring or Play! several of them are > configured this way and it requires no XML (where the container needs such > files, the framework generates them;-) > > Werner > > On Fri, Sep 5, 2014 at 10:21 PM, 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) > 2. Re: With the end of Java Config... (Anatole Tresch) > 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition > (Anatole Tresch (JIRA)) > 4. Re: With the end of Java Config... (Jens Schumann) > > ------------------------------ > > Message: 4 > Date: Fri, 5 Sep 2014 20:20:53 +0000 > From: Jens Schumann > Subject: Re: [cdi-dev] With the end of Java Config... > To: Anatole Tresch , Antonio Goncalves > > Cc: cdi-dev > Message-ID: > Content-Type: text/plain; charset="windows-1252" > > I can confirm that this approach works very well. We are using a similar > approach a couple of years now, and I love the simplicity that comes with > portable extensions and @Producer methods. See our public version here [1] > (works since early CDI 1.0 days) . > > Instead of a @Inject + Qualifier we just use the qualifier @Property. We > support default values and type conversation for primitives and everything > that has a string based constructor. The property source can be anything, > from property files (default) to databases or xml files. For examples see > tests here [2]. > > Nevertheless I am not sure if this should be part of an future CDI spec. > My concerns include the bloat argument, of course. But the main reason > relates to the fact that we have almost everything in the current CDI spec > already. > > Right now I am quite happy with an custom portable extension that does > everything for me. At the time we implemented the extension we realised > that the "hard part" was writing an extension that links a qualified > "optional injection point" with an @Producer method while supporting code > based default values. Luckily I had Arne in my team who did that within a > few minutes. > > Because of this experience I would propose that we simplify extension > development such that "optional injection points" may be linked to > @Produces values easily. Additionally we have to solve a few more > integration issues (e.g. read-only DB access should be available during CDI > startup). Everything else should be provided by portable extensions (e.g. > via delta-spike) and documentation/howtos at cdi-spec.org. > > Jens > [1] > https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property > [2] > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property > > Von: Anatole Tresch > > Datum: Friday 5 September 2014 21:22 > An: Antonio Goncalves antonio.goncalves at gmail.com>> > Cc: CDI-Dev > > Betreff: Re: [cdi-dev] With the end of Java Config... > > Hi all, > > I would not like to add an XML "bloated" mechanism as part of CDI 2.0. > Spontaneously I would propose a more CDI like things like: > > > * Adding a @Configured annotation (basically a qualifier). This can be > in addition to @Inject and would allow to inject "configured" values. > * Since configuration can change we may think of a (CDI) > event/reinject mechanism based on config changes. By default, this is > switched off and we can discuss how it would be activated, e.g. by an > additional flag settable with the @Configured annotation, or an additional > @Observable ConfigChangeEvent (similar to the Griffon framework), or both. > * Hereby configured values theoretically behave similar as all other > injection points. They also can be qualified (the aspect of scopes, I did > not yet have time to think about). The only difference is, that they are > satisified using the configuration "system". > * The configuration "source" itself could in the extreme simplest way > be a Provider>. The CDI spec should not care about how > this map is provided (XML, DB, overrides, etc). This still can be > standardized later. As long as the ConfigurationSource SPI is defined, > companies still can hook in the logic and level of configuration > abstraction they need. > * Of course, since not only Strings can be injected, we need some > conversion or adapter logic as basically outlined in my blog. Also here we > can add a simple SPI and let the details to the RI. > > Summarizing a > > * @Configured annotation > * some kind of change event > * a ConfigurationSource extends Provider> > * a conversion mechanism from String to T. > > we get a full fledged configuration mechanism that leverages CDI. > > That would be my idea basically. WDYT? I will try to work that out in more > details. Basically it should be implementable even with the CDI mechanism > already in place with CDI 1.1. > > Best, > Anatole > > > > > > > 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >: > One wise man* once said "EJB was a hype specification, we added too many > things to it, it became bloated. The next hype specifications are JAX-RS > and CDI, careful with them" > > Either we get this idea of "parts" right, or CDI will endup being bloated. > > Antonio > > > *David Blevin > > > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > Hi all, > > You may have followed the rise and fall of the Java Config JSR ( > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > ). > Anatole in CC was leading this initiative and I proposed him to join us > and explore if some part of his late-JSR could be done in CDI. > > I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or related > solution. If we achieve to have a majority of specs to integrate with CDI, > our configuration solution would therefore become a configuration system > for all spec based on CDI 2.0. > > 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. > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter< > http://twitter.com/agoncal> | LinkedIn > | Pluralsight< > http://pluralsight.com/training/Authors/Details/antonio-goncalves> | > Paris JUG | Devoxx France > > _______________________________________________ > 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. > > > > -- > Anatole Tresch > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > Switzerland, Europe Zurich, GMT+1 > Twitter: @atsticks > Blogs: http://javaremarkables.blogspot.ch/ > Google: atsticks > Mobile +41-76 344 62 79 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 > *************************************** > > > > _______________________________________________ > 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. > > > > > -- > *Anatole Tresch* > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > * > > *Google: atsticksMobile +41-76 344 62 79* > > _______________________________________________ > 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/20140907/215e43d3/attachment-0001.html From john.d.ament at gmail.com Sun Sep 7 08:52:51 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 7 Sep 2014 08:52:51 -0400 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Actually, as of AS7 JBoss did this with most settings, and as of WildFly 8 anything I could think of could be done via property placeholders (there were a bunch of missing places). I personally like this approach. What I end up doing is something like this: ${http.cookies.secure:false} ... It'll use the config value, if found, and if not found use the default value specified in the placeholder (false). Locally we don't run SSL, but in our external deployments we do, so we just leave it unset locally and give a template properties file for devops to fill in for deployments. Much easier. We end up using puppet currently, which seems to like having placeholders over placeholders, so our template properties will look like http.cookies.secure=facters['some config prop'] or something along those lines. Then when it gets deployed the file is generated. On Sun, Sep 7, 2014 at 8:46 AM, Mark Struberg wrote: > Yes, the config group also was (obviously) looking at DeltaSpikes config > mechanism as well. > There were others who wanted to go more into the 'filtering' approach as > done on WebLogic servers (though not sure who else does that as well). > You know, having all the XML configs like WEB-INF/web.xml containing > placeholders and the real values only get placed in there at deployment > time. I personally find this approach a bit limited from a technical > perspective and it already didn't work out for me when using WebLogic (what > about changing a configured value after the deployment was done? What about > security? Having passwords in web.xml, unit testing, ...). > There are of course also other approaches which all might have strong > sides and would have needed to get discussed. > > But utterly the problem seems to have been legal reasons. We even offered > to have Anatole/CS lead the EG and do the RI as an ASF project with > substantial support and participation from the JBoss, DeltaSpike and TomEE > communities. > > Anyway, the time will come when we will resurrect this effort. > > LieGrue, > strub > > > > > On Sunday, 7 September 2014, 14:29, Werner Keil > wrote: > > > > Yep, it contains a simple but extendable notion of ProjectStage, too;-) > > > On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament > wrote: > > Anatole, > > I'm wondering if some of your configuration description falls under what > was put together in DeltaSpike? > > http://deltaspike.apache.org/configuration.html > > John > > > On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch wrote: > > Staging is not a question of xml or not xml (the "format" of config). You > can do staged config also using xml, or based on a database or json config > service. Staging as well as, more generally speaking, environment dependent > config is more like to select/filter the right config that *targets *the > current (runtime) environment. This might include stages, but also many > other aspects are feasible and common (server, tier, ear, war, tenant ...). > Since these aspects are per se very complex, it might be advisable to leave > them out of any spec (even a dedicated config JSR would probably not be > capable of covering these within the relatively short EE timeframe)... > > > 2014-09-05 23:30 GMT+02:00 Werner Keil : > > Jens/all, > > A sort of "staging" already was possible using CDI earlier, see examples > like this: > > http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war > > DeltaSpike also includes type-safe staging that goes beyond the primitive, > hard-coded JSF enum. > > If that works without XML, while still allowing flexible configuration for > different stages or to add and "inject" additional stages maybe even on a > tenant basis (for Cloud scenarios) I could see something like that work > without XML. In the Multiconf project we managed to code everything in > Python, and similar to Puppet or Chef you can configure and deploy multiple > environments with it, Java EE, Spring or Play! several of them are > configured this way and it requires no XML (where the container needs such > files, the framework generates them;-) > > Werner > > On Fri, Sep 5, 2014 at 10:21 PM, 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) > 2. Re: With the end of Java Config... (Anatole Tresch) > 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition > (Anatole Tresch (JIRA)) > 4. Re: With the end of Java Config... (Jens Schumann) > > ------------------------------ > > Message: 4 > Date: Fri, 5 Sep 2014 20:20:53 +0000 > From: Jens Schumann > Subject: Re: [cdi-dev] With the end of Java Config... > To: Anatole Tresch , Antonio Goncalves > > Cc: cdi-dev > Message-ID: > Content-Type: text/plain; charset="windows-1252" > > I can confirm that this approach works very well. We are using a similar > approach a couple of years now, and I love the simplicity that comes with > portable extensions and @Producer methods. See our public version here [1] > (works since early CDI 1.0 days) . > > Instead of a @Inject + Qualifier we just use the qualifier @Property. We > support default values and type conversation for primitives and everything > that has a string based constructor. The property source can be anything, > from property files (default) to databases or xml files. For examples see > tests here [2]. > > Nevertheless I am not sure if this should be part of an future CDI spec. > My concerns include the bloat argument, of course. But the main reason > relates to the fact that we have almost everything in the current CDI spec > already. > > Right now I am quite happy with an custom portable extension that does > everything for me. At the time we implemented the extension we realised > that the "hard part" was writing an extension that links a qualified > "optional injection point" with an @Producer method while supporting code > based default values. Luckily I had Arne in my team who did that within a > few minutes. > > Because of this experience I would propose that we simplify extension > development such that "optional injection points" may be linked to > @Produces values easily. Additionally we have to solve a few more > integration issues (e.g. read-only DB access should be available during CDI > startup). Everything else should be provided by portable extensions (e.g. > via delta-spike) and documentation/howtos at cdi-spec.org. > > Jens > [1] > https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property > [2] > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property > > Von: Anatole Tresch > > Datum: Friday 5 September 2014 21:22 > An: Antonio Goncalves antonio.goncalves at gmail.com>> > Cc: CDI-Dev > > Betreff: Re: [cdi-dev] With the end of Java Config... > > Hi all, > > I would not like to add an XML "bloated" mechanism as part of CDI 2.0. > Spontaneously I would propose a more CDI like things like: > > > * Adding a @Configured annotation (basically a qualifier). This can be > in addition to @Inject and would allow to inject "configured" values. > * Since configuration can change we may think of a (CDI) > event/reinject mechanism based on config changes. By default, this is > switched off and we can discuss how it would be activated, e.g. by an > additional flag settable with the @Configured annotation, or an additional > @Observable ConfigChangeEvent (similar to the Griffon framework), or both. > * Hereby configured values theoretically behave similar as all other > injection points. They also can be qualified (the aspect of scopes, I did > not yet have time to think about). The only difference is, that they are > satisified using the configuration "system". > * The configuration "source" itself could in the extreme simplest way > be a Provider>. The CDI spec should not care about how > this map is provided (XML, DB, overrides, etc). This still can be > standardized later. As long as the ConfigurationSource SPI is defined, > companies still can hook in the logic and level of configuration > abstraction they need. > * Of course, since not only Strings can be injected, we need some > conversion or adapter logic as basically outlined in my blog. Also here we > can add a simple SPI and let the details to the RI. > > Summarizing a > > * @Configured annotation > * some kind of change event > * a ConfigurationSource extends Provider> > * a conversion mechanism from String to T. > > we get a full fledged configuration mechanism that leverages CDI. > > That would be my idea basically. WDYT? I will try to work that out in more > details. Basically it should be implementable even with the CDI mechanism > already in place with CDI 1.1. > > Best, > Anatole > > > > > > > 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >: > One wise man* once said "EJB was a hype specification, we added too many > things to it, it became bloated. The next hype specifications are JAX-RS > and CDI, careful with them" > > Either we get this idea of "parts" right, or CDI will endup being bloated. > > Antonio > > > *David Blevin > > > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > Hi all, > > You may have followed the rise and fall of the Java Config JSR ( > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > ). > Anatole in CC was leading this initiative and I proposed him to join us > and explore if some part of his late-JSR could be done in CDI. > > I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or related > solution. If we achieve to have a majority of specs to integrate with CDI, > our configuration solution would therefore become a configuration system > for all spec based on CDI 2.0. > > 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. > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter< > http://twitter.com/agoncal> | LinkedIn > | Pluralsight< > http://pluralsight.com/training/Authors/Details/antonio-goncalves> | > Paris JUG | Devoxx France > > _______________________________________________ > 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. > > > > -- > Anatole Tresch > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > Switzerland, Europe Zurich, GMT+1 > Twitter: @atsticks > Blogs: http://javaremarkables.blogspot.ch/ > Google: atsticks > Mobile +41-76 344 62 79 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 > *************************************** > > > > _______________________________________________ > 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. > > > > > -- > *Anatole Tresch* > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > * > > *Google: atsticksMobile +41-76 344 62 79* > > _______________________________________________ > 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/20140907/bcd3aa22/attachment-0001.html From struberg at yahoo.de Sun Sep 7 11:26:01 2014 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 7 Sep 2014 16:26:01 +0100 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: <1410103561.39612.YahooMailNeo@web28904.mail.ir2.yahoo.com> The downside I see with this approach are:1.) where to apply this? This mechanism must also work in unit tests and at development time in your IDE 2.) it's not portable 3.) it has security issues as the expanding is done at deploy-time 4.) Thus this does not work well for anything sensible like user credentials, etc 5.) it is not anywhere near dynamic - it really requires a re-deployment if you like to change the config. This is not practicable for apps which run for years. of course, other approaches have other downsides as well... LieGrue, strub On Sunday, 7 September 2014, 14:52, John D. Ament wrote: > > >Actually, as of AS7 JBoss did this with most settings, and as of WildFly 8 anything I could think of could be done via property placeholders (there were a bunch of missing places). > > >I personally like this approach. What I end up doing is something like this: > > > > > ${http.cookies.secure:false} >... > > > > >It'll use the config value, if found, and if not found use the default value specified in the placeholder (false). Locally we don't run SSL, but in our external deployments we do, so we just leave it unset locally and give a template properties file for devops to fill in for deployments. Much easier. > > >We end up using puppet currently, which seems to like having placeholders over placeholders, so our template properties will look like > > >http.cookies.secure=facters['some config prop'] > > >or something along those lines. Then when it gets deployed the file is generated. > > > >On Sun, Sep 7, 2014 at 8:46 AM, Mark Struberg wrote: > >Yes, the config group also was (obviously) looking at DeltaSpikes config mechanism as well. >>There were others who wanted to go more into the 'filtering' approach as done on WebLogic servers (though not sure who else does that as well). >>You know, having all the XML configs like WEB-INF/web.xml containing placeholders and the real values only get placed in there at deployment time. I personally find this approach a bit limited from a technical perspective and it already didn't work out for me when using WebLogic (what about changing a configured value after the deployment was done? What about security? Having passwords in web.xml, unit testing, ...). >>There are of course also other approaches which all might have strong sides and would have needed to get discussed. >> >> >> >>But utterly the problem seems to have been legal reasons. We even offered to have Anatole/CS lead the EG and do the RI as an ASF project with substantial support and participation from the JBoss, DeltaSpike and TomEE communities. >> >> >>Anyway, the time will come when we will resurrect this effort. >> >> >>LieGrue, >>strub >> >> >> >> >> >> >> >> >>On Sunday, 7 September 2014, 14:29, Werner Keil wrote: >> >> >>> >>> >>>Yep, it contains a simple but extendable notion of ProjectStage, too;-) >>> >>> >>> >>>On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament wrote: >>> >>>Anatole, >>>> >>>> >>>>I'm wondering if some of your configuration description falls under what was put together in DeltaSpike? >>>> >>>> >>>>http://deltaspike.apache.org/configuration.html >>>> >>>> >>>> >>>>John >>>> >>>> >>>> >>>>On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch wrote: >>>> >>>>Staging is not a question of xml or not xml (the "format" of config). You can do staged config also using xml, or based on a database or json config service. Staging as well as, more generally speaking, environment dependent config is more like to select/filter the right config that targets the current (runtime) environment. This might include stages, but also many other aspects are feasible and common (server, tier, ear, war, tenant ...). Since these aspects are per se very complex, it might be advisable to leave them out of any spec (even a dedicated config JSR would probably not be capable of covering these within the relatively short EE timeframe)... >>>>> >>>>> >>>>> >>>>> >>>>>2014-09-05 23:30 GMT+02:00 Werner Keil : >>>>> >>>>>Jens/all, >>>>>> >>>>>> >>>>>>A sort of "staging" already was possible using CDI earlier, see examples like this: >>>>>>http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >>>>>> >>>>>> >>>>>>DeltaSpike also includes type-safe staging that goes beyond the primitive, hard-coded JSF enum. >>>>>> >>>>>> >>>>>>If that works without XML, while still allowing flexible configuration for different stages or to add and "inject" additional stages maybe even on a tenant basis (for Cloud scenarios) I could see something like that work without XML. In the Multiconf project we managed to code everything in Python, and similar to Puppet or Chef you can configure and deploy multiple environments with it, Java EE, Spring or Play! several of them are configured this way and it requires no XML (where the container needs such files, the framework generates them;-) >>>>>> >>>>>> >>>>>>Werner >>>>>> >>>>>> >>>>>>On Fri, Sep 5, 2014 at 10:21 PM, 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) >>>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >>>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>>>>>> (Anatole Tresch (JIRA)) >>>>>>> 4. Re: With the end of Java Config... (Jens Schumann) >>>>>>> >>>>>>>------------------------------ >>>>>>> >>>>>>>Message: 4 >>>>>>>Date: Fri, 5 Sep 2014 20:20:53 +0000 >>>>>>>From: Jens Schumann >>>>>>>Subject: Re: [cdi-dev] With the end of Java Config... >>>>>>>To: Anatole Tresch , Antonio Goncalves >>>>>>> >>>>>>>Cc: cdi-dev >>>>>>>Message-ID: >>>>>>>Content-Type: text/plain; charset="windows-1252" >>>>>>> >>>>>>>I can confirm that this approach works very well. We are using a similar approach a couple of years now, and I love the simplicity that comes with portable extensions and @Producer methods. See our public version here [1] (works since early CDI 1.0 days) . >>>>>>> >>>>>>>Instead of a @Inject + Qualifier we just use the qualifier @Property. We support default values and type conversation for primitives and everything that has a string based constructor. The property source can be anything, from property files (default) to databases or xml files. For examples see tests here [2]. >>>>>>> >>>>>>>Nevertheless I am not sure if this should be part of an future CDI spec. My concerns include the bloat argument, of course. But the main reason relates to the fact that we have almost everything in the current CDI spec already. >>>>>>> >>>>>>>Right now I am quite happy with an custom portable extension that does everything for me. At the time we implemented the extension we realised that the "hard part" was writing an extension that links a qualified "optional injection point" with an @Producer method while supporting code based default values. Luckily I had Arne in my team who did that within a few minutes. >>>>>>> >>>>>>>Because of this experience I would propose that we simplify extension development such that "optional injection points" may be linked to @Produces values easily. Additionally we have to solve a few more integration issues (e.g. read-only DB access should be available during CDI startup). Everything else should be provided by portable extensions (e.g. via delta-spike) and documentation/howtos at cdi-spec.org. >>>>>>> >>>>>>>Jens >>>>>>>[1] https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>>>>>>[2] https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>>>>>> >>>>>>> Von: Anatole Tresch > >>>>>>>Datum: Friday 5 September 2014 21:22 >>>>>>> An: Antonio Goncalves > >>>>>>>Cc: CDI-Dev > >>>>>>>Betreff: Re: [cdi-dev] With the end of Java Config... >>>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I would not like to add an XML "bloated" mechanism as part of CDI 2.0. Spontaneously I would propose a more CDI like things like: >>>>>>> >>>>>>> >>>>>>> * Adding a @Configured annotation (basically a qualifier). This can be in addition to @Inject and would allow to inject "configured" values. >>>>>>> * Since configuration can change we may think of a (CDI) event/reinject mechanism based on config changes. By default, this is switched off and we can discuss how it would be activated, e.g. by an additional flag settable with the @Configured annotation, or an additional @Observable ConfigChangeEvent (similar to the Griffon framework), or both. >>>>>>> * Hereby configured values theoretically behave similar as all other injection points. They also can be qualified (the aspect of scopes, I did not yet have time to think about). The only difference is, that they are satisified using the configuration "system". >>>>>>> * The configuration "source" itself could in the extreme simplest way be a Provider>. The CDI spec should not care about how this map is provided (XML, DB, overrides, etc). This still can be standardized later. As long as the ConfigurationSource SPI is defined, companies still can hook in the logic and level of configuration abstraction they need. >>>>>>> * Of course, since not only Strings can be injected, we need some conversion or adapter logic as basically outlined in my blog. Also here we can add a simple SPI and let the details to the RI. >>>>>>> >>>>>>>Summarizing a >>>>>>> >>>>>>> * @Configured annotation >>>>>>> * some kind of change event >>>>>>> * a ConfigurationSource extends Provider> >>>>>>> * a conversion mechanism from String to T. >>>>>>> >>>>>>>we get a full fledged configuration mechanism that leverages CDI. >>>>>>> >>>>>>>That would be my idea basically. WDYT? I will try to work that out in more details. Basically it should be implementable even with the CDI mechanism already in place with CDI 1.1. >>>>>>> >>>>>>>Best, >>>>>>>Anatole >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >: >>>>>>>One wise man* once said "EJB was a hype specification, we added too many things to it, it became bloated. The next hype specifications are JAX-RS and CDI, careful with them" >>>>>>> >>>>>>>Either we get this idea of "parts" right, or CDI will endup being bloated. >>>>>>> >>>>>>>Antonio >>>>>>> >>>>>>> >>>>>>>*David Blevin >>>>>>> >>>>>>> >>>>>>>On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand > wrote: >>>>>>>Hi all, >>>>>>> >>>>>>>You may have followed the rise and fall of the Java Config JSR (http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html). >>>>>>>Anatole in CC was leading this initiative and I proposed him to join us and explore if some part of his late-JSR could be done in CDI. >>>>>>> >>>>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or related solution. If we achieve to have a majority of specs to integrate with CDI, our configuration solution would therefore become a configuration system for all spec based on CDI 2.0. >>>>>>> >>>>>>>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. >>>>>>> >>>>>>> >>>>>>> >>>>>>>-- >>>>>>>Antonio Goncalves >>>>>>>Software architect, Java Champion and Pluralsight author >>>>>>> >>>>>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >>>>>>> >>>>>>>_______________________________________________ >>>>>>>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. >>>>>>> >>>>>>> >>>>>>> >>>>>>>-- >>>>>>>Anatole Tresch >>>>>>>Java Lead Engineer, JSR Spec Lead >>>>>>> Gl?rnischweg 10 >>>>>>>CH - 8620 Wetzikon >>>>>>> >>>>>>>Switzerland, Europe Zurich, GMT+1 >>>>>>>Twitter: @atsticks >>>>>>>Blogs: http://javaremarkables.blogspot.ch/ >>>>>>>Google: atsticks >>>>>>>Mobile +41-76 344 62 79 >>>>>>>-------------- next part -------------- >>>>>>>An HTML attachment was scrubbed... >>>>>>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>>>>>>*************************************** >>>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>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. >>>>>> >>>>> >>>>> >>>>> >>>>>-- >>>>> >>>>>Anatole Tresch >>>>>Java Lead Engineer, JSR Spec Lead >>>>>Gl?rnischweg 10 >>>>>CH - 8620 Wetzikon >>>>> >>>>> >>>>>Switzerland, Europe Zurich, GMT+1 >>>>>Twitter: @atsticks >>>>>Blogs: http://javaremarkables.blogspot.ch/ >>>>>Google: atsticks >>>>>Mobile +41-76 344 62 79 >>>>>_______________________________________________ >>>>>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/20140907/c08c0cec/attachment-0001.html From atsticks at gmail.com Sun Sep 7 15:12:51 2014 From: atsticks at gmail.com (Anatole Tresch) Date: Sun, 7 Sep 2014 21:12:51 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Hi All unfortunately things seem quite complicated: - first of all,* similarities with Deltaspike are basically not accidental*. The concepts we developed in Credit Suisse are very similar to Deltaspike, though Deltaspike was not yet born at that time. Fortunately we ended up with a similar kind of solution. - *filtering still can be done.* My idea is to define some kind of "configuration provider", which then is dynamically asked for configuration. How the provider is internally organized, is completely transparent to CDI. This enables to have multi-layered, complex config solutions work the same (from a view point of CDI) like simple programmatic test configurations during unit tests. The config provider still can support filtering and dynamic resolution as commonly used in configuration systems. Similarly the format is basically also not fixed. Of course, would a reference implementation provide a set of functionalities, but I would definitively not define the exact configuration mechanism as part of the CDI (or even a EE config JSR). Another reason, beside complexity and time, is the fact that different companies handle, store and manage configuration differently, so a mechanism must be flexible enough to accommodate these, without adoption rate will be low. Furthermore this flexibility also keeps doors open for use cases we do not know yet. - Also we have to separate some basically *two types of configuration aspects:* - *application config *basically is injected into deployed components, but basically only can affect deployment to the extend it can be managed and injected by CDI. The basic architecture and design, how application servers to load and deploy are basically not affected. This type of configuration (mechanism) I see also as a possible addition to CDI, if we really fail to do something in another JSR. With CDI going for a more modular design, even basic configuration of CDI can be possible, given we have some kind of API, we can access during CDI initialization. - On the other side *deployment configuration *affects directly how the application server deploys the application. Configuration here would allow to define datasources, EJBs, transactional aspects, security, persistence, war and ear configurations etc. Basically everything you do as of today with some kind of XML file, or annotation. Hereby enabling more flexibility into the existing descriptors is relatively easy, but as mentioned by Mark, constraint. Adding more flexibility raises other subtle problems. Imagine a application module, e.g. a war, that defines everything it requires. There is no need to configure anything more on server side (with spring you can do this, with Java EE unfortunately not). But this has a severe consequence, it would make the application really portable in the sense, that it can be moved between different app servers (vendors) without any change (ideally). As a result commercial profits of some vendor companies may be affected. I think this is actually one of the key points, why things are getting so complicated in that area. - *Legal aspects* also were discussed. One of them is a possible legal clash of ALv2 with GPL. This is the case already within Glassfish, but one of the reasons, why ALv2 was not acceptable to Oracle's legal department. At the end we decided to use a BSD model. Even dual licensing BSD/ALv2 could theoretically be an option. If you would choose ALv2, Oracle will not include your RI into Glassfish, which is the RI for the EE Umbrella JSR, meaning your JSR will not be included into EE8. So what should we do? I don't have a good answer... So, I like to discuss configuration aspects here. Nevertheless if we decide to add config aspects, be aware that we might only (mainly) support application config, since everything else directly would impact other JSRs. And that is obviously quite similar to what Apache Deltaspike is all about ;-) Cheers, Anatole 2014-09-07 14:46 GMT+02:00 Mark Struberg : > Yes, the config group also was (obviously) looking at DeltaSpikes config > mechanism as well. > There were others who wanted to go more into the 'filtering' approach as > done on WebLogic servers (though not sure who else does that as well). > You know, having all the XML configs like WEB-INF/web.xml containing > placeholders and the real values only get placed in there at deployment > time. I personally find this approach a bit limited from a technical > perspective and it already didn't work out for me when using WebLogic (what > about changing a configured value after the deployment was done? What about > security? Having passwords in web.xml, unit testing, ...). > There are of course also other approaches which all might have strong > sides and would have needed to get discussed. > > But utterly the problem seems to have been legal reasons. We even offered > to have Anatole/CS lead the EG and do the RI as an ASF project with > substantial support and participation from the JBoss, DeltaSpike and TomEE > communities. > > Anyway, the time will come when we will resurrect this effort. > > LieGrue, > strub > > > > > On Sunday, 7 September 2014, 14:29, Werner Keil > wrote: > > > > Yep, it contains a simple but extendable notion of ProjectStage, too;-) > > > On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament > wrote: > > Anatole, > > I'm wondering if some of your configuration description falls under what > was put together in DeltaSpike? > > http://deltaspike.apache.org/configuration.html > > John > > > On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch wrote: > > Staging is not a question of xml or not xml (the "format" of config). You > can do staged config also using xml, or based on a database or json config > service. Staging as well as, more generally speaking, environment dependent > config is more like to select/filter the right config that *targets *the > current (runtime) environment. This might include stages, but also many > other aspects are feasible and common (server, tier, ear, war, tenant ...). > Since these aspects are per se very complex, it might be advisable to leave > them out of any spec (even a dedicated config JSR would probably not be > capable of covering these within the relatively short EE timeframe)... > > > 2014-09-05 23:30 GMT+02:00 Werner Keil : > > Jens/all, > > A sort of "staging" already was possible using CDI earlier, see examples > like this: > > http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war > > DeltaSpike also includes type-safe staging that goes beyond the primitive, > hard-coded JSF enum. > > If that works without XML, while still allowing flexible configuration for > different stages or to add and "inject" additional stages maybe even on a > tenant basis (for Cloud scenarios) I could see something like that work > without XML. In the Multiconf project we managed to code everything in > Python, and similar to Puppet or Chef you can configure and deploy multiple > environments with it, Java EE, Spring or Play! several of them are > configured this way and it requires no XML (where the container needs such > files, the framework generates them;-) > > Werner > > On Fri, Sep 5, 2014 at 10:21 PM, 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) > 2. Re: With the end of Java Config... (Anatole Tresch) > 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition > (Anatole Tresch (JIRA)) > 4. Re: With the end of Java Config... (Jens Schumann) > > ------------------------------ > > Message: 4 > Date: Fri, 5 Sep 2014 20:20:53 +0000 > From: Jens Schumann > Subject: Re: [cdi-dev] With the end of Java Config... > To: Anatole Tresch , Antonio Goncalves > > Cc: cdi-dev > Message-ID: > Content-Type: text/plain; charset="windows-1252" > > I can confirm that this approach works very well. We are using a similar > approach a couple of years now, and I love the simplicity that comes with > portable extensions and @Producer methods. See our public version here [1] > (works since early CDI 1.0 days) . > > Instead of a @Inject + Qualifier we just use the qualifier @Property. We > support default values and type conversation for primitives and everything > that has a string based constructor. The property source can be anything, > from property files (default) to databases or xml files. For examples see > tests here [2]. > > Nevertheless I am not sure if this should be part of an future CDI spec. > My concerns include the bloat argument, of course. But the main reason > relates to the fact that we have almost everything in the current CDI spec > already. > > Right now I am quite happy with an custom portable extension that does > everything for me. At the time we implemented the extension we realised > that the "hard part" was writing an extension that links a qualified > "optional injection point" with an @Producer method while supporting code > based default values. Luckily I had Arne in my team who did that within a > few minutes. > > Because of this experience I would propose that we simplify extension > development such that "optional injection points" may be linked to > @Produces values easily. Additionally we have to solve a few more > integration issues (e.g. read-only DB access should be available during CDI > startup). Everything else should be provided by portable extensions (e.g. > via delta-spike) and documentation/howtos at cdi-spec.org. > > Jens > [1] > https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property > [2] > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property > > Von: Anatole Tresch > > Datum: Friday 5 September 2014 21:22 > An: Antonio Goncalves antonio.goncalves at gmail.com>> > Cc: CDI-Dev > > Betreff: Re: [cdi-dev] With the end of Java Config... > > Hi all, > > I would not like to add an XML "bloated" mechanism as part of CDI 2.0. > Spontaneously I would propose a more CDI like things like: > > > * Adding a @Configured annotation (basically a qualifier). This can be > in addition to @Inject and would allow to inject "configured" values. > * Since configuration can change we may think of a (CDI) > event/reinject mechanism based on config changes. By default, this is > switched off and we can discuss how it would be activated, e.g. by an > additional flag settable with the @Configured annotation, or an additional > @Observable ConfigChangeEvent (similar to the Griffon framework), or both. > * Hereby configured values theoretically behave similar as all other > injection points. They also can be qualified (the aspect of scopes, I did > not yet have time to think about). The only difference is, that they are > satisified using the configuration "system". > * The configuration "source" itself could in the extreme simplest way > be a Provider>. The CDI spec should not care about how > this map is provided (XML, DB, overrides, etc). This still can be > standardized later. As long as the ConfigurationSource SPI is defined, > companies still can hook in the logic and level of configuration > abstraction they need. > * Of course, since not only Strings can be injected, we need some > conversion or adapter logic as basically outlined in my blog. Also here we > can add a simple SPI and let the details to the RI. > > Summarizing a > > * @Configured annotation > * some kind of change event > * a ConfigurationSource extends Provider> > * a conversion mechanism from String to T. > > we get a full fledged configuration mechanism that leverages CDI. > > That would be my idea basically. WDYT? I will try to work that out in more > details. Basically it should be implementable even with the CDI mechanism > already in place with CDI 1.1. > > Best, > Anatole > > > > > > > 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >: > One wise man* once said "EJB was a hype specification, we added too many > things to it, it became bloated. The next hype specifications are JAX-RS > and CDI, careful with them" > > Either we get this idea of "parts" right, or CDI will endup being bloated. > > Antonio > > > *David Blevin > > > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > Hi all, > > You may have followed the rise and fall of the Java Config JSR ( > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > ). > Anatole in CC was leading this initiative and I proposed him to join us > and explore if some part of his late-JSR could be done in CDI. > > I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or related > solution. If we achieve to have a majority of specs to integrate with CDI, > our configuration solution would therefore become a configuration system > for all spec based on CDI 2.0. > > 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. > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter< > http://twitter.com/agoncal> | LinkedIn > | Pluralsight< > http://pluralsight.com/training/Authors/Details/antonio-goncalves> | > Paris JUG | Devoxx France > > _______________________________________________ > 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. > > > > -- > Anatole Tresch > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > Switzerland, Europe Zurich, GMT+1 > Twitter: @atsticks > Blogs: http://javaremarkables.blogspot.ch/ > Google: atsticks > Mobile +41-76 344 62 79 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 > *************************************** > > > > _______________________________________________ > 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. > > > > > -- > *Anatole Tresch* > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > * > > *Google: atsticksMobile +41-76 344 62 79* > > _______________________________________________ > 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. > > > > _______________________________________________ > 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. > -- *Anatole Tresch* Java Lead Engineer, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140907/637de480/attachment-0001.html From john.d.ament at gmail.com Sun Sep 7 15:26:30 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 7 Sep 2014 15:26:30 -0400 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: <1410103561.39612.YahooMailNeo@web28904.mail.ir2.yahoo.com> References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> <1410103561.39612.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Mark, What approach are you referring to? I don't see how any of this has to do with variables, seems like your bigger concern is that deployment descriptors cannot be modified at runtime. On Sun, Sep 7, 2014 at 11:26 AM, Mark Struberg wrote: > The downside I see with this approach are: > 1.) where to apply this? This mechanism must also work in unit tests and > at development time in your IDE > 2.) it's not portable > 3.) it has security issues as the expanding is done at deploy-time > 4.) Thus this does not work well for anything sensible like user > credentials, etc > 5.) it is not anywhere near dynamic - it really requires a re-deployment > if you like to change the config. This is not practicable for apps which > run for years. > > of course, other approaches have other downsides as well... > > LieGrue, > strub > > > > On Sunday, 7 September 2014, 14:52, John D. Ament < > john.d.ament at gmail.com> wrote: > > > > Actually, as of AS7 JBoss did this with most settings, and as of WildFly 8 > anything I could think of could be done via property placeholders (there > were a bunch of missing places). > > I personally like this approach. What I end up doing is something like > this: > > > > ${http.cookies.secure:false} > ... > > > It'll use the config value, if found, and if not found use the default > value specified in the placeholder (false). Locally we don't run SSL, but > in our external deployments we do, so we just leave it unset locally and > give a template properties file for devops to fill in for deployments. > Much easier. > > We end up using puppet currently, which seems to like having placeholders > over placeholders, so our template properties will look like > > http.cookies.secure=facters['some config prop'] > > or something along those lines. Then when it gets deployed the file is > generated. > > > On Sun, Sep 7, 2014 at 8:46 AM, Mark Struberg wrote: > > Yes, the config group also was (obviously) looking at DeltaSpikes config > mechanism as well. > There were others who wanted to go more into the 'filtering' approach as > done on WebLogic servers (though not sure who else does that as well). > You know, having all the XML configs like WEB-INF/web.xml containing > placeholders and the real values only get placed in there at deployment > time. I personally find this approach a bit limited from a technical > perspective and it already didn't work out for me when using WebLogic (what > about changing a configured value after the deployment was done? What about > security? Having passwords in web.xml, unit testing, ...). > There are of course also other approaches which all might have strong > sides and would have needed to get discussed. > > But utterly the problem seems to have been legal reasons. We even offered > to have Anatole/CS lead the EG and do the RI as an ASF project with > substantial support and participation from the JBoss, DeltaSpike and TomEE > communities. > > Anyway, the time will come when we will resurrect this effort. > > LieGrue, > strub > > > > > On Sunday, 7 September 2014, 14:29, Werner Keil > wrote: > > > > Yep, it contains a simple but extendable notion of ProjectStage, too;-) > > > On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament > wrote: > > Anatole, > > I'm wondering if some of your configuration description falls under what > was put together in DeltaSpike? > > http://deltaspike.apache.org/configuration.html > > John > > > On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch wrote: > > Staging is not a question of xml or not xml (the "format" of config). You > can do staged config also using xml, or based on a database or json config > service. Staging as well as, more generally speaking, environment dependent > config is more like to select/filter the right config that *targets *the > current (runtime) environment. This might include stages, but also many > other aspects are feasible and common (server, tier, ear, war, tenant ...). > Since these aspects are per se very complex, it might be advisable to leave > them out of any spec (even a dedicated config JSR would probably not be > capable of covering these within the relatively short EE timeframe)... > > > 2014-09-05 23:30 GMT+02:00 Werner Keil : > > Jens/all, > > A sort of "staging" already was possible using CDI earlier, see examples > like this: > > http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war > > DeltaSpike also includes type-safe staging that goes beyond the primitive, > hard-coded JSF enum. > > If that works without XML, while still allowing flexible configuration for > different stages or to add and "inject" additional stages maybe even on a > tenant basis (for Cloud scenarios) I could see something like that work > without XML. In the Multiconf project we managed to code everything in > Python, and similar to Puppet or Chef you can configure and deploy multiple > environments with it, Java EE, Spring or Play! several of them are > configured this way and it requires no XML (where the container needs such > files, the framework generates them;-) > > Werner > > On Fri, Sep 5, 2014 at 10:21 PM, 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) > 2. Re: With the end of Java Config... (Anatole Tresch) > 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition > (Anatole Tresch (JIRA)) > 4. Re: With the end of Java Config... (Jens Schumann) > > ------------------------------ > > Message: 4 > Date: Fri, 5 Sep 2014 20:20:53 +0000 > From: Jens Schumann > Subject: Re: [cdi-dev] With the end of Java Config... > To: Anatole Tresch , Antonio Goncalves > > Cc: cdi-dev > Message-ID: > Content-Type: text/plain; charset="windows-1252" > > I can confirm that this approach works very well. We are using a similar > approach a couple of years now, and I love the simplicity that comes with > portable extensions and @Producer methods. See our public version here [1] > (works since early CDI 1.0 days) . > > Instead of a @Inject + Qualifier we just use the qualifier @Property. We > support default values and type conversation for primitives and everything > that has a string based constructor. The property source can be anything, > from property files (default) to databases or xml files. For examples see > tests here [2]. > > Nevertheless I am not sure if this should be part of an future CDI spec. > My concerns include the bloat argument, of course. But the main reason > relates to the fact that we have almost everything in the current CDI spec > already. > > Right now I am quite happy with an custom portable extension that does > everything for me. At the time we implemented the extension we realised > that the "hard part" was writing an extension that links a qualified > "optional injection point" with an @Producer method while supporting code > based default values. Luckily I had Arne in my team who did that within a > few minutes. > > Because of this experience I would propose that we simplify extension > development such that "optional injection points" may be linked to > @Produces values easily. Additionally we have to solve a few more > integration issues (e.g. read-only DB access should be available during CDI > startup). Everything else should be provided by portable extensions (e.g. > via delta-spike) and documentation/howtos at cdi-spec.org. > > Jens > [1] > https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property > [2] > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property > > Von: Anatole Tresch > > Datum: Friday 5 September 2014 21:22 > An: Antonio Goncalves antonio.goncalves at gmail.com>> > Cc: CDI-Dev > > Betreff: Re: [cdi-dev] With the end of Java Config... > > Hi all, > > I would not like to add an XML "bloated" mechanism as part of CDI 2.0. > Spontaneously I would propose a more CDI like things like: > > > * Adding a @Configured annotation (basically a qualifier). This can be > in addition to @Inject and would allow to inject "configured" values. > * Since configuration can change we may think of a (CDI) > event/reinject mechanism based on config changes. By default, this is > switched off and we can discuss how it would be activated, e.g. by an > additional flag settable with the @Configured annotation, or an additional > @Observable ConfigChangeEvent (similar to the Griffon framework), or both. > * Hereby configured values theoretically behave similar as all other > injection points. They also can be qualified (the aspect of scopes, I did > not yet have time to think about). The only difference is, that they are > satisified using the configuration "system". > * The configuration "source" itself could in the extreme simplest way > be a Provider>. The CDI spec should not care about how > this map is provided (XML, DB, overrides, etc). This still can be > standardized later. As long as the ConfigurationSource SPI is defined, > companies still can hook in the logic and level of configuration > abstraction they need. > * Of course, since not only Strings can be injected, we need some > conversion or adapter logic as basically outlined in my blog. Also here we > can add a simple SPI and let the details to the RI. > > Summarizing a > > * @Configured annotation > * some kind of change event > * a ConfigurationSource extends Provider> > * a conversion mechanism from String to T. > > we get a full fledged configuration mechanism that leverages CDI. > > That would be my idea basically. WDYT? I will try to work that out in more > details. Basically it should be implementable even with the CDI mechanism > already in place with CDI 1.1. > > Best, > Anatole > > > > > > > 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >: > One wise man* once said "EJB was a hype specification, we added too many > things to it, it became bloated. The next hype specifications are JAX-RS > and CDI, careful with them" > > Either we get this idea of "parts" right, or CDI will endup being bloated. > > Antonio > > > *David Blevin > > > On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > Hi all, > > You may have followed the rise and fall of the Java Config JSR ( > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > ). > Anatole in CC was leading this initiative and I proposed him to join us > and explore if some part of his late-JSR could be done in CDI. > > I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or related > solution. If we achieve to have a majority of specs to integrate with CDI, > our configuration solution would therefore become a configuration system > for all spec based on CDI 2.0. > > 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. > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter< > http://twitter.com/agoncal> | LinkedIn > | Pluralsight< > http://pluralsight.com/training/Authors/Details/antonio-goncalves> | > Paris JUG | Devoxx France > > _______________________________________________ > 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. > > > > -- > Anatole Tresch > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > Switzerland, Europe Zurich, GMT+1 > Twitter: @atsticks > Blogs: http://javaremarkables.blogspot.ch/ > Google: atsticks > Mobile +41-76 344 62 79 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 > *************************************** > > > > _______________________________________________ > 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. > > > > > -- > *Anatole Tresch* > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > * > > *Google: atsticksMobile +41-76 344 62 79* > > _______________________________________________ > 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/20140907/e43bc977/attachment-0001.html From john.d.ament at gmail.com Sun Sep 7 15:28:17 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 7 Sep 2014 15:28:17 -0400 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Ok, this mail has me more concerned than anything. Can you clarify this ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch wrote: > Hi All > > unfortunately things seem quite complicated: > > - first of all,* similarities with Deltaspike are basically not > accidental*. The concepts we developed in Credit Suisse are very > similar to Deltaspike, though Deltaspike was not yet born at that time. > Fortunately we ended up with a similar kind of solution. > - *filtering still can be done.* My idea is to define some kind of > "configuration provider", which then is dynamically asked for > configuration. How the provider is internally organized, is completely > transparent to CDI. This enables to have multi-layered, complex config > solutions work the same (from a view point of CDI) like simple programmatic > test configurations during unit tests. The config provider still can > support filtering and dynamic resolution as commonly used in configuration > systems. Similarly the format is basically also not fixed. Of course, would > a reference implementation provide a set of functionalities, but I would > definitively not define the exact configuration mechanism as part of the > CDI (or even a EE config JSR). Another reason, beside complexity and time, > is the fact that different companies handle, store and manage configuration > differently, so a mechanism must be flexible enough to accommodate these, > without adoption rate will be low. Furthermore this flexibility also keeps > doors open for use cases we do not know yet. > - Also we have to separate some basically *two types of configuration > aspects:* > - *application config *basically is injected into deployed > components, but basically only can affect deployment to the extend it can > be managed and injected by CDI. The basic architecture and design, how > application servers to load and deploy are basically not affected. This > type of configuration (mechanism) I see also as a possible addition to CDI, > if we really fail to do something in another JSR. With CDI going for a more > modular design, even basic configuration of CDI can be possible, given we > have some kind of API, we can access during CDI initialization. > - On the other side *deployment configuration *affects directly how > the application server deploys the application. Configuration here would > allow to define datasources, EJBs, transactional aspects, security, > persistence, war and ear configurations etc. Basically everything you do as > of today with some kind of XML file, or annotation. Hereby enabling more > flexibility into the existing descriptors is relatively easy, but as > mentioned by Mark, constraint. Adding more flexibility raises other subtle > problems. Imagine a application module, e.g. a war, that defines everything > it requires. There is no need to configure anything more on server side > (with spring you can do this, with Java EE unfortunately not). But this has > a severe consequence, it would make the application really portable in the > sense, that it can be moved between different app servers (vendors) without > any change (ideally). As a result commercial profits of some vendor > companies may be affected. I think this is actually one of the key points, > why things are getting so complicated in that area. > - *Legal aspects* also were discussed. One of them is a possible legal > clash of ALv2 with GPL. This is the case already within Glassfish, but one > of the reasons, why ALv2 was not acceptable to Oracle's legal department. > At the end we decided to use a BSD model. Even dual licensing BSD/ALv2 > could theoretically be an option. If you would choose ALv2, Oracle will not > include your RI into Glassfish, which is the RI for the EE Umbrella JSR, > meaning your JSR will not be included into EE8. So what should we do? I > don't have a good answer... > > So, I like to discuss configuration aspects here. Nevertheless if we > decide to add config aspects, be aware that we might only (mainly) support > application config, since everything else directly would impact other JSRs. > And that is obviously quite similar to what Apache Deltaspike is all about > ;-) > > Cheers, > Anatole > > > > > 2014-09-07 14:46 GMT+02:00 Mark Struberg : > >> Yes, the config group also was (obviously) looking at DeltaSpikes config >> mechanism as well. >> There were others who wanted to go more into the 'filtering' approach as >> done on WebLogic servers (though not sure who else does that as well). >> You know, having all the XML configs like WEB-INF/web.xml containing >> placeholders and the real values only get placed in there at deployment >> time. I personally find this approach a bit limited from a technical >> perspective and it already didn't work out for me when using WebLogic (what >> about changing a configured value after the deployment was done? What about >> security? Having passwords in web.xml, unit testing, ...). >> There are of course also other approaches which all might have strong >> sides and would have needed to get discussed. >> >> But utterly the problem seems to have been legal reasons. We even offered >> to have Anatole/CS lead the EG and do the RI as an ASF project with >> substantial support and participation from the JBoss, DeltaSpike and TomEE >> communities. >> >> Anyway, the time will come when we will resurrect this effort. >> >> LieGrue, >> strub >> >> >> >> >> On Sunday, 7 September 2014, 14:29, Werner Keil >> wrote: >> >> >> >> Yep, it contains a simple but extendable notion of ProjectStage, too;-) >> >> >> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament >> wrote: >> >> Anatole, >> >> I'm wondering if some of your configuration description falls under what >> was put together in DeltaSpike? >> >> http://deltaspike.apache.org/configuration.html >> >> John >> >> >> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch >> wrote: >> >> Staging is not a question of xml or not xml (the "format" of config). You >> can do staged config also using xml, or based on a database or json config >> service. Staging as well as, more generally speaking, environment dependent >> config is more like to select/filter the right config that *targets *the >> current (runtime) environment. This might include stages, but also many >> other aspects are feasible and common (server, tier, ear, war, tenant ...). >> Since these aspects are per se very complex, it might be advisable to leave >> them out of any spec (even a dedicated config JSR would probably not be >> capable of covering these within the relatively short EE timeframe)... >> >> >> 2014-09-05 23:30 GMT+02:00 Werner Keil : >> >> Jens/all, >> >> A sort of "staging" already was possible using CDI earlier, see examples >> like this: >> >> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >> >> DeltaSpike also includes type-safe staging that goes beyond the >> primitive, hard-coded JSF enum. >> >> If that works without XML, while still allowing flexible configuration >> for different stages or to add and "inject" additional stages maybe even >> on a tenant basis (for Cloud scenarios) I could see something like that >> work without XML. In the Multiconf project we managed to code everything in >> Python, and similar to Puppet or Chef you can configure and deploy multiple >> environments with it, Java EE, Spring or Play! several of them are >> configured this way and it requires no XML (where the container needs such >> files, the framework generates them;-) >> >> Werner >> >> On Fri, Sep 5, 2014 at 10:21 PM, 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) >> 2. Re: With the end of Java Config... (Anatole Tresch) >> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >> (Anatole Tresch (JIRA)) >> 4. Re: With the end of Java Config... (Jens Schumann) >> >> ------------------------------ >> >> Message: 4 >> Date: Fri, 5 Sep 2014 20:20:53 +0000 >> From: Jens Schumann >> Subject: Re: [cdi-dev] With the end of Java Config... >> To: Anatole Tresch , Antonio Goncalves >> >> Cc: cdi-dev >> Message-ID: >> Content-Type: text/plain; charset="windows-1252" >> >> I can confirm that this approach works very well. We are using a similar >> approach a couple of years now, and I love the simplicity that comes with >> portable extensions and @Producer methods. See our public version here [1] >> (works since early CDI 1.0 days) . >> >> Instead of a @Inject + Qualifier we just use the qualifier @Property. We >> support default values and type conversation for primitives and everything >> that has a string based constructor. The property source can be anything, >> from property files (default) to databases or xml files. For examples see >> tests here [2]. >> >> Nevertheless I am not sure if this should be part of an future CDI spec. >> My concerns include the bloat argument, of course. But the main reason >> relates to the fact that we have almost everything in the current CDI spec >> already. >> >> Right now I am quite happy with an custom portable extension that does >> everything for me. At the time we implemented the extension we realised >> that the "hard part" was writing an extension that links a qualified >> "optional injection point" with an @Producer method while supporting code >> based default values. Luckily I had Arne in my team who did that within a >> few minutes. >> >> Because of this experience I would propose that we simplify extension >> development such that "optional injection points" may be linked to >> @Produces values easily. Additionally we have to solve a few more >> integration issues (e.g. read-only DB access should be available during CDI >> startup). Everything else should be provided by portable extensions (e.g. >> via delta-spike) and documentation/howtos at cdi-spec.org. >> >> Jens >> [1] >> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >> [2] >> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >> >> Von: Anatole Tresch > >> Datum: Friday 5 September 2014 21:22 >> An: Antonio Goncalves > antonio.goncalves at gmail.com>> >> Cc: CDI-Dev > >> Betreff: Re: [cdi-dev] With the end of Java Config... >> >> Hi all, >> >> I would not like to add an XML "bloated" mechanism as part of CDI 2.0. >> Spontaneously I would propose a more CDI like things like: >> >> >> * Adding a @Configured annotation (basically a qualifier). This can >> be in addition to @Inject and would allow to inject "configured" values. >> * Since configuration can change we may think of a (CDI) >> event/reinject mechanism based on config changes. By default, this is >> switched off and we can discuss how it would be activated, e.g. by an >> additional flag settable with the @Configured annotation, or an additional >> @Observable ConfigChangeEvent (similar to the Griffon framework), or both. >> * Hereby configured values theoretically behave similar as all other >> injection points. They also can be qualified (the aspect of scopes, I did >> not yet have time to think about). The only difference is, that they are >> satisified using the configuration "system". >> * The configuration "source" itself could in the extreme simplest way >> be a Provider>. The CDI spec should not care about how >> this map is provided (XML, DB, overrides, etc). This still can be >> standardized later. As long as the ConfigurationSource SPI is defined, >> companies still can hook in the logic and level of configuration >> abstraction they need. >> * Of course, since not only Strings can be injected, we need some >> conversion or adapter logic as basically outlined in my blog. Also here we >> can add a simple SPI and let the details to the RI. >> >> Summarizing a >> >> * @Configured annotation >> * some kind of change event >> * a ConfigurationSource extends Provider> >> * a conversion mechanism from String to T. >> >> we get a full fledged configuration mechanism that leverages CDI. >> >> That would be my idea basically. WDYT? I will try to work that out in >> more details. Basically it should be implementable even with the CDI >> mechanism already in place with CDI 1.1. >> >> Best, >> Anatole >> >> >> >> >> >> >> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves > >: >> One wise man* once said "EJB was a hype specification, we added too many >> things to it, it became bloated. The next hype specifications are JAX-RS >> and CDI, careful with them" >> >> Either we get this idea of "parts" right, or CDI will endup being bloated. >> >> Antonio >> >> >> *David Blevin >> >> >> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> Hi all, >> >> You may have followed the rise and fall of the Java Config JSR ( >> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >> ). >> Anatole in CC was leading this initiative and I proposed him to join us >> and explore if some part of his late-JSR could be done in CDI. >> >> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >> related solution. If we achieve to have a majority of specs to integrate >> with CDI, our configuration solution would therefore become a configuration >> system for all spec based on CDI 2.0. >> >> 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. >> >> >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter< >> http://twitter.com/agoncal> | LinkedIn >> | Pluralsight< >> http://pluralsight.com/training/Authors/Details/antonio-goncalves> | >> Paris JUG | Devoxx France >> >> _______________________________________________ >> 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. >> >> >> >> -- >> Anatole Tresch >> Java Lead Engineer, JSR Spec Lead >> Gl?rnischweg 10 >> CH - 8620 Wetzikon >> >> Switzerland, Europe Zurich, GMT+1 >> Twitter: @atsticks >> Blogs: http://javaremarkables.blogspot.ch/ >> Google: atsticks >> Mobile +41-76 344 62 79 >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >> *************************************** >> >> >> >> _______________________________________________ >> 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. >> >> >> >> >> -- >> *Anatole Tresch* >> Java Lead Engineer, JSR Spec Lead >> Gl?rnischweg 10 >> CH - 8620 Wetzikon >> >> *Switzerland, Europe Zurich, GMT+1* >> *Twitter: @atsticks* >> *Blogs: **http://javaremarkables.blogspot.ch/ >> * >> >> *Google: atsticksMobile +41-76 344 62 79* >> >> _______________________________________________ >> 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. >> >> >> >> _______________________________________________ >> 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. >> > > > > -- > *Anatole Tresch* > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > * > > *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140907/3c2e1330/attachment-0001.html From werner.keil at gmail.com Sun Sep 7 15:44:09 2014 From: werner.keil at gmail.com (Werner Keil) Date: Sun, 7 Sep 2014 21:44:09 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under ALv2 as a dual-license, this was discussed by EC Members but both JCP EC and Oracle Legal/PMO seems fine with it, and CDI is already an essential building block to Java EE 6/7, hence used with Glassfish, too. I wasn't involved in these discussions, but given CDI is especially liberal and fully accepted by JCP formalities and license policies, I don't really see what the problem wss for Anatole's JSR attempt (though I know, both Oracle and other EC Members/companies don't always prefer this kind of licensing...;-) Werner On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament wrote: > Ok, this mail has me more concerned than anything. Can you clarify this > ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. > > On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch wrote: > >> Hi All >> >> unfortunately things seem quite complicated: >> >> - first of all,* similarities with Deltaspike are basically not >> accidental*. The concepts we developed in Credit Suisse are very >> similar to Deltaspike, though Deltaspike was not yet born at that time. >> Fortunately we ended up with a similar kind of solution. >> - *filtering still can be done.* My idea is to define some kind of >> "configuration provider", which then is dynamically asked for >> configuration. How the provider is internally organized, is completely >> transparent to CDI. This enables to have multi-layered, complex config >> solutions work the same (from a view point of CDI) like simple programmatic >> test configurations during unit tests. The config provider still can >> support filtering and dynamic resolution as commonly used in configuration >> systems. Similarly the format is basically also not fixed. Of course, would >> a reference implementation provide a set of functionalities, but I would >> definitively not define the exact configuration mechanism as part of the >> CDI (or even a EE config JSR). Another reason, beside complexity and time, >> is the fact that different companies handle, store and manage configuration >> differently, so a mechanism must be flexible enough to accommodate these, >> without adoption rate will be low. Furthermore this flexibility also keeps >> doors open for use cases we do not know yet. >> - Also we have to separate some basically *two types of configuration >> aspects:* >> - *application config *basically is injected into deployed >> components, but basically only can affect deployment to the extend it can >> be managed and injected by CDI. The basic architecture and design, how >> application servers to load and deploy are basically not affected. This >> type of configuration (mechanism) I see also as a possible addition to CDI, >> if we really fail to do something in another JSR. With CDI going for a more >> modular design, even basic configuration of CDI can be possible, given we >> have some kind of API, we can access during CDI initialization. >> - On the other side *deployment configuration *affects directly >> how the application server deploys the application. Configuration here >> would allow to define datasources, EJBs, transactional aspects, security, >> persistence, war and ear configurations etc. Basically everything you do as >> of today with some kind of XML file, or annotation. Hereby enabling more >> flexibility into the existing descriptors is relatively easy, but as >> mentioned by Mark, constraint. Adding more flexibility raises other subtle >> problems. Imagine a application module, e.g. a war, that defines everything >> it requires. There is no need to configure anything more on server side >> (with spring you can do this, with Java EE unfortunately not). But this has >> a severe consequence, it would make the application really portable in the >> sense, that it can be moved between different app servers (vendors) without >> any change (ideally). As a result commercial profits of some vendor >> companies may be affected. I think this is actually one of the key points, >> why things are getting so complicated in that area. >> - *Legal aspects* also were discussed. One of them is a possible >> legal clash of ALv2 with GPL. This is the case already within Glassfish, >> but one of the reasons, why ALv2 was not acceptable to Oracle's legal >> department. At the end we decided to use a BSD model. Even dual licensing >> BSD/ALv2 could theoretically be an option. If you would choose ALv2, Oracle >> will not include your RI into Glassfish, which is the RI for the EE >> Umbrella JSR, meaning your JSR will not be included into EE8. So what >> should we do? I don't have a good answer... >> >> So, I like to discuss configuration aspects here. Nevertheless if we >> decide to add config aspects, be aware that we might only (mainly) support >> application config, since everything else directly would impact other JSRs. >> And that is obviously quite similar to what Apache Deltaspike is all about >> ;-) >> >> Cheers, >> Anatole >> >> >> >> >> 2014-09-07 14:46 GMT+02:00 Mark Struberg : >> >>> Yes, the config group also was (obviously) looking at DeltaSpikes config >>> mechanism as well. >>> There were others who wanted to go more into the 'filtering' approach as >>> done on WebLogic servers (though not sure who else does that as well). >>> You know, having all the XML configs like WEB-INF/web.xml containing >>> placeholders and the real values only get placed in there at deployment >>> time. I personally find this approach a bit limited from a technical >>> perspective and it already didn't work out for me when using WebLogic (what >>> about changing a configured value after the deployment was done? What about >>> security? Having passwords in web.xml, unit testing, ...). >>> There are of course also other approaches which all might have strong >>> sides and would have needed to get discussed. >>> >>> But utterly the problem seems to have been legal reasons. We even >>> offered to have Anatole/CS lead the EG and do the RI as an ASF project with >>> substantial support and participation from the JBoss, DeltaSpike and TomEE >>> communities. >>> >>> Anyway, the time will come when we will resurrect this effort. >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> On Sunday, 7 September 2014, 14:29, Werner Keil >>> wrote: >>> >>> >>> >>> Yep, it contains a simple but extendable notion of ProjectStage, too;-) >>> >>> >>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament >>> wrote: >>> >>> Anatole, >>> >>> I'm wondering if some of your configuration description falls under what >>> was put together in DeltaSpike? >>> >>> http://deltaspike.apache.org/configuration.html >>> >>> John >>> >>> >>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch >>> wrote: >>> >>> Staging is not a question of xml or not xml (the "format" of config). >>> You can do staged config also using xml, or based on a database or json >>> config service. Staging as well as, more generally speaking, environment >>> dependent config is more like to select/filter the right config that >>> *targets *the current (runtime) environment. This might include stages, >>> but also many other aspects are feasible and common (server, tier, ear, >>> war, tenant ...). Since these aspects are per se very complex, it might be >>> advisable to leave them out of any spec (even a dedicated config JSR would >>> probably not be capable of covering these within the relatively short EE >>> timeframe)... >>> >>> >>> 2014-09-05 23:30 GMT+02:00 Werner Keil : >>> >>> Jens/all, >>> >>> A sort of "staging" already was possible using CDI earlier, see examples >>> like this: >>> >>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >>> >>> DeltaSpike also includes type-safe staging that goes beyond the >>> primitive, hard-coded JSF enum. >>> >>> If that works without XML, while still allowing flexible configuration >>> for different stages or to add and "inject" additional stages maybe even >>> on a tenant basis (for Cloud scenarios) I could see something like that >>> work without XML. In the Multiconf project we managed to code everything in >>> Python, and similar to Puppet or Chef you can configure and deploy multiple >>> environments with it, Java EE, Spring or Play! several of them are >>> configured this way and it requires no XML (where the container needs such >>> files, the framework generates them;-) >>> >>> Werner >>> >>> On Fri, Sep 5, 2014 at 10:21 PM, >>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) >>> 2. Re: With the end of Java Config... (Anatole Tresch) >>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>> (Anatole Tresch (JIRA)) >>> 4. Re: With the end of Java Config... (Jens Schumann) >>> >>> ------------------------------ >>> >>> Message: 4 >>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >>> From: Jens Schumann >>> Subject: Re: [cdi-dev] With the end of Java Config... >>> To: Anatole Tresch , Antonio Goncalves >>> >>> Cc: cdi-dev >>> Message-ID: >>> Content-Type: text/plain; charset="windows-1252" >>> >>> I can confirm that this approach works very well. We are using a similar >>> approach a couple of years now, and I love the simplicity that comes with >>> portable extensions and @Producer methods. See our public version here [1] >>> (works since early CDI 1.0 days) . >>> >>> Instead of a @Inject + Qualifier we just use the qualifier @Property. We >>> support default values and type conversation for primitives and everything >>> that has a string based constructor. The property source can be anything, >>> from property files (default) to databases or xml files. For examples see >>> tests here [2]. >>> >>> Nevertheless I am not sure if this should be part of an future CDI spec. >>> My concerns include the bloat argument, of course. But the main reason >>> relates to the fact that we have almost everything in the current CDI spec >>> already. >>> >>> Right now I am quite happy with an custom portable extension that does >>> everything for me. At the time we implemented the extension we realised >>> that the "hard part" was writing an extension that links a qualified >>> "optional injection point" with an @Producer method while supporting code >>> based default values. Luckily I had Arne in my team who did that within a >>> few minutes. >>> >>> Because of this experience I would propose that we simplify extension >>> development such that "optional injection points" may be linked to >>> @Produces values easily. Additionally we have to solve a few more >>> integration issues (e.g. read-only DB access should be available during CDI >>> startup). Everything else should be provided by portable extensions (e.g. >>> via delta-spike) and documentation/howtos at cdi-spec.org. >>> >>> Jens >>> [1] >>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>> [2] >>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>> >>> Von: Anatole Tresch > >>> Datum: Friday 5 September 2014 21:22 >>> An: Antonio Goncalves >> antonio.goncalves at gmail.com>> >>> Cc: CDI-Dev > >>> Betreff: Re: [cdi-dev] With the end of Java Config... >>> >>> Hi all, >>> >>> I would not like to add an XML "bloated" mechanism as part of CDI 2.0. >>> Spontaneously I would propose a more CDI like things like: >>> >>> >>> * Adding a @Configured annotation (basically a qualifier). This can >>> be in addition to @Inject and would allow to inject "configured" values. >>> * Since configuration can change we may think of a (CDI) >>> event/reinject mechanism based on config changes. By default, this is >>> switched off and we can discuss how it would be activated, e.g. by an >>> additional flag settable with the @Configured annotation, or an additional >>> @Observable ConfigChangeEvent (similar to the Griffon framework), or both. >>> * Hereby configured values theoretically behave similar as all other >>> injection points. They also can be qualified (the aspect of scopes, I did >>> not yet have time to think about). The only difference is, that they are >>> satisified using the configuration "system". >>> * The configuration "source" itself could in the extreme simplest >>> way be a Provider>. The CDI spec should not care about >>> how this map is provided (XML, DB, overrides, etc). This still can be >>> standardized later. As long as the ConfigurationSource SPI is defined, >>> companies still can hook in the logic and level of configuration >>> abstraction they need. >>> * Of course, since not only Strings can be injected, we need some >>> conversion or adapter logic as basically outlined in my blog. Also here we >>> can add a simple SPI and let the details to the RI. >>> >>> Summarizing a >>> >>> * @Configured annotation >>> * some kind of change event >>> * a ConfigurationSource extends Provider> >>> * a conversion mechanism from String to T. >>> >>> we get a full fledged configuration mechanism that leverages CDI. >>> >>> That would be my idea basically. WDYT? I will try to work that out in >>> more details. Basically it should be implementable even with the CDI >>> mechanism already in place with CDI 1.1. >>> >>> Best, >>> Anatole >>> >>> >>> >>> >>> >>> >>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves < >>> antonio.goncalves at gmail.com>: >>> One wise man* once said "EJB was a hype specification, we added too many >>> things to it, it became bloated. The next hype specifications are JAX-RS >>> and CDI, careful with them" >>> >>> Either we get this idea of "parts" right, or CDI will endup being >>> bloated. >>> >>> Antonio >>> >>> >>> *David Blevin >>> >>> >>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < >>> antoine at sabot-durand.net> wrote: >>> Hi all, >>> >>> You may have followed the rise and fall of the Java Config JSR ( >>> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >>> ). >>> Anatole in CC was leading this initiative and I proposed him to join us >>> and explore if some part of his late-JSR could be done in CDI. >>> >>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >>> related solution. If we achieve to have a majority of specs to integrate >>> with CDI, our configuration solution would therefore become a configuration >>> system for all spec based on CDI 2.0. >>> >>> 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. >>> >>> >>> >>> -- >>> Antonio Goncalves >>> Software architect, Java Champion and Pluralsight author >>> >>> Web site | Twitter< >>> http://twitter.com/agoncal> | LinkedIn< >>> http://www.linkedin.com/in/agoncal> | Pluralsight< >>> http://pluralsight.com/training/Authors/Details/antonio-goncalves> | >>> Paris JUG | Devoxx France >>> >>> _______________________________________________ >>> 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. >>> >>> >>> >>> -- >>> Anatole Tresch >>> Java Lead Engineer, JSR Spec Lead >>> Gl?rnischweg 10 >>> CH - 8620 Wetzikon >>> >>> Switzerland, Europe Zurich, GMT+1 >>> Twitter: @atsticks >>> Blogs: http://javaremarkables.blogspot.ch/ >>> Google: atsticks >>> Mobile +41-76 344 62 79 >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>> *************************************** >>> >>> >>> >>> _______________________________________________ >>> 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. >>> >>> >>> >>> >>> -- >>> *Anatole Tresch* >>> Java Lead Engineer, JSR Spec Lead >>> Gl?rnischweg 10 >>> CH - 8620 Wetzikon >>> >>> *Switzerland, Europe Zurich, GMT+1* >>> *Twitter: @atsticks* >>> *Blogs: **http://javaremarkables.blogspot.ch/ >>> * >>> >>> *Google: atsticksMobile +41-76 344 62 79* >>> >>> _______________________________________________ >>> 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. >>> >>> >>> >>> _______________________________________________ >>> 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. >>> >> >> >> >> -- >> *Anatole Tresch* >> Java Lead Engineer, JSR Spec Lead >> Gl?rnischweg 10 >> CH - 8620 Wetzikon >> >> *Switzerland, Europe Zurich, GMT+1* >> *Twitter: @atsticks* >> *Blogs: **http://javaremarkables.blogspot.ch/ >> * >> >> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140907/2181ce4f/attachment-0001.html From atsticks at gmail.com Sun Sep 7 17:32:33 2014 From: atsticks at gmail.com (Anatole Tresch) Date: Sun, 7 Sep 2014 23:32:33 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: I would not worry about CDI regarding licensing. Just the sentence was that Oracle does not want to have more ALv2 in addition to what is already there. So as long as we do things within CDI, no worries, I think. For new EE JSRs nevertheless this is a BIG issue and should be clarified by the EC! 2014-09-07 21:44 GMT+02:00 Werner Keil : > Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under ALv2 as > a dual-license, this was discussed by EC Members but both JCP EC and Oracle > Legal/PMO seems fine with it, and CDI is already an essential building > block to Java EE 6/7, hence used with Glassfish, too. I wasn't involved in > these discussions, but given CDI is especially liberal and fully accepted > by JCP formalities and license policies, I don't really see what the > problem wss for Anatole's JSR attempt (though I know, both Oracle and other > EC Members/companies don't always prefer this kind of licensing...;-) > > Werner > > On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament > wrote: > >> Ok, this mail has me more concerned than anything. Can you clarify this >> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. >> >> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch >> wrote: >> >>> Hi All >>> >>> unfortunately things seem quite complicated: >>> >>> - first of all,* similarities with Deltaspike are basically not >>> accidental*. The concepts we developed in Credit Suisse are very >>> similar to Deltaspike, though Deltaspike was not yet born at that time. >>> Fortunately we ended up with a similar kind of solution. >>> - *filtering still can be done.* My idea is to define some kind of >>> "configuration provider", which then is dynamically asked for >>> configuration. How the provider is internally organized, is completely >>> transparent to CDI. This enables to have multi-layered, complex config >>> solutions work the same (from a view point of CDI) like simple programmatic >>> test configurations during unit tests. The config provider still can >>> support filtering and dynamic resolution as commonly used in configuration >>> systems. Similarly the format is basically also not fixed. Of course, would >>> a reference implementation provide a set of functionalities, but I would >>> definitively not define the exact configuration mechanism as part of the >>> CDI (or even a EE config JSR). Another reason, beside complexity and time, >>> is the fact that different companies handle, store and manage configuration >>> differently, so a mechanism must be flexible enough to accommodate these, >>> without adoption rate will be low. Furthermore this flexibility also keeps >>> doors open for use cases we do not know yet. >>> - Also we have to separate some basically *two types of >>> configuration aspects:* >>> - *application config *basically is injected into deployed >>> components, but basically only can affect deployment to the extend it can >>> be managed and injected by CDI. The basic architecture and design, how >>> application servers to load and deploy are basically not affected. This >>> type of configuration (mechanism) I see also as a possible addition to CDI, >>> if we really fail to do something in another JSR. With CDI going for a more >>> modular design, even basic configuration of CDI can be possible, given we >>> have some kind of API, we can access during CDI initialization. >>> - On the other side *deployment configuration *affects directly >>> how the application server deploys the application. Configuration here >>> would allow to define datasources, EJBs, transactional aspects, security, >>> persistence, war and ear configurations etc. Basically everything you do as >>> of today with some kind of XML file, or annotation. Hereby enabling more >>> flexibility into the existing descriptors is relatively easy, but as >>> mentioned by Mark, constraint. Adding more flexibility raises other subtle >>> problems. Imagine a application module, e.g. a war, that defines everything >>> it requires. There is no need to configure anything more on server side >>> (with spring you can do this, with Java EE unfortunately not). But this has >>> a severe consequence, it would make the application really portable in the >>> sense, that it can be moved between different app servers (vendors) without >>> any change (ideally). As a result commercial profits of some vendor >>> companies may be affected. I think this is actually one of the key points, >>> why things are getting so complicated in that area. >>> - *Legal aspects* also were discussed. One of them is a possible >>> legal clash of ALv2 with GPL. This is the case already within Glassfish, >>> but one of the reasons, why ALv2 was not acceptable to Oracle's legal >>> department. At the end we decided to use a BSD model. Even dual licensing >>> BSD/ALv2 could theoretically be an option. If you would choose ALv2, Oracle >>> will not include your RI into Glassfish, which is the RI for the EE >>> Umbrella JSR, meaning your JSR will not be included into EE8. So what >>> should we do? I don't have a good answer... >>> >>> So, I like to discuss configuration aspects here. Nevertheless if we >>> decide to add config aspects, be aware that we might only (mainly) support >>> application config, since everything else directly would impact other JSRs. >>> And that is obviously quite similar to what Apache Deltaspike is all about >>> ;-) >>> >>> Cheers, >>> Anatole >>> >>> >>> >>> >>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : >>> >>>> Yes, the config group also was (obviously) looking at DeltaSpikes >>>> config mechanism as well. >>>> There were others who wanted to go more into the 'filtering' approach >>>> as done on WebLogic servers (though not sure who else does that as well). >>>> You know, having all the XML configs like WEB-INF/web.xml containing >>>> placeholders and the real values only get placed in there at deployment >>>> time. I personally find this approach a bit limited from a technical >>>> perspective and it already didn't work out for me when using WebLogic (what >>>> about changing a configured value after the deployment was done? What about >>>> security? Having passwords in web.xml, unit testing, ...). >>>> There are of course also other approaches which all might have strong >>>> sides and would have needed to get discussed. >>>> >>>> But utterly the problem seems to have been legal reasons. We even >>>> offered to have Anatole/CS lead the EG and do the RI as an ASF project with >>>> substantial support and participation from the JBoss, DeltaSpike and TomEE >>>> communities. >>>> >>>> Anyway, the time will come when we will resurrect this effort. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> >>>> On Sunday, 7 September 2014, 14:29, Werner Keil < >>>> werner.keil at gmail.com> wrote: >>>> >>>> >>>> >>>> Yep, it contains a simple but extendable notion of ProjectStage, too;-) >>>> >>>> >>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament >>>> wrote: >>>> >>>> Anatole, >>>> >>>> I'm wondering if some of your configuration description falls under >>>> what was put together in DeltaSpike? >>>> >>>> http://deltaspike.apache.org/configuration.html >>>> >>>> John >>>> >>>> >>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch >>>> wrote: >>>> >>>> Staging is not a question of xml or not xml (the "format" of config). >>>> You can do staged config also using xml, or based on a database or json >>>> config service. Staging as well as, more generally speaking, environment >>>> dependent config is more like to select/filter the right config that >>>> *targets *the current (runtime) environment. This might include >>>> stages, but also many other aspects are feasible and common (server, tier, >>>> ear, war, tenant ...). Since these aspects are per se very complex, it >>>> might be advisable to leave them out of any spec (even a dedicated config >>>> JSR would probably not be capable of covering these within the relatively >>>> short EE timeframe)... >>>> >>>> >>>> 2014-09-05 23:30 GMT+02:00 Werner Keil : >>>> >>>> Jens/all, >>>> >>>> A sort of "staging" already was possible using CDI earlier, see >>>> examples like this: >>>> >>>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >>>> >>>> DeltaSpike also includes type-safe staging that goes beyond the >>>> primitive, hard-coded JSF enum. >>>> >>>> If that works without XML, while still allowing flexible configuration >>>> for different stages or to add and "inject" additional stages maybe even >>>> on a tenant basis (for Cloud scenarios) I could see something like that >>>> work without XML. In the Multiconf project we managed to code everything in >>>> Python, and similar to Puppet or Chef you can configure and deploy multiple >>>> environments with it, Java EE, Spring or Play! several of them are >>>> configured this way and it requires no XML (where the container needs such >>>> files, the framework generates them;-) >>>> >>>> Werner >>>> >>>> On Fri, Sep 5, 2014 at 10:21 PM, >>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) >>>> 2. Re: With the end of Java Config... (Anatole Tresch) >>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>>> (Anatole Tresch (JIRA)) >>>> 4. Re: With the end of Java Config... (Jens Schumann) >>>> >>>> ------------------------------ >>>> >>>> Message: 4 >>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >>>> From: Jens Schumann >>>> Subject: Re: [cdi-dev] With the end of Java Config... >>>> To: Anatole Tresch , Antonio Goncalves >>>> >>>> Cc: cdi-dev >>>> Message-ID: >>>> Content-Type: text/plain; charset="windows-1252" >>>> >>>> I can confirm that this approach works very well. We are using a >>>> similar approach a couple of years now, and I love the simplicity that >>>> comes with portable extensions and @Producer methods. See our public >>>> version here [1] (works since early CDI 1.0 days) . >>>> >>>> Instead of a @Inject + Qualifier we just use the qualifier @Property. >>>> We support default values and type conversation for primitives and >>>> everything that has a string based constructor. The property source can be >>>> anything, from property files (default) to databases or xml files. For >>>> examples see tests here [2]. >>>> >>>> Nevertheless I am not sure if this should be part of an future CDI >>>> spec. My concerns include the bloat argument, of course. But the main >>>> reason relates to the fact that we have almost everything in the current >>>> CDI spec already. >>>> >>>> Right now I am quite happy with an custom portable extension that does >>>> everything for me. At the time we implemented the extension we realised >>>> that the "hard part" was writing an extension that links a qualified >>>> "optional injection point" with an @Producer method while supporting code >>>> based default values. Luckily I had Arne in my team who did that within a >>>> few minutes. >>>> >>>> Because of this experience I would propose that we simplify extension >>>> development such that "optional injection points" may be linked to >>>> @Produces values easily. Additionally we have to solve a few more >>>> integration issues (e.g. read-only DB access should be available during CDI >>>> startup). Everything else should be provided by portable extensions (e.g. >>>> via delta-spike) and documentation/howtos at cdi-spec.org. >>>> >>>> Jens >>>> [1] >>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>>> [2] >>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>>> >>>> Von: Anatole Tresch > >>>> Datum: Friday 5 September 2014 21:22 >>>> An: Antonio Goncalves >>> antonio.goncalves at gmail.com>> >>>> Cc: CDI-Dev > >>>> Betreff: Re: [cdi-dev] With the end of Java Config... >>>> >>>> Hi all, >>>> >>>> I would not like to add an XML "bloated" mechanism as part of CDI 2.0. >>>> Spontaneously I would propose a more CDI like things like: >>>> >>>> >>>> * Adding a @Configured annotation (basically a qualifier). This can >>>> be in addition to @Inject and would allow to inject "configured" values. >>>> * Since configuration can change we may think of a (CDI) >>>> event/reinject mechanism based on config changes. By default, this is >>>> switched off and we can discuss how it would be activated, e.g. by an >>>> additional flag settable with the @Configured annotation, or an additional >>>> @Observable ConfigChangeEvent (similar to the Griffon framework), or both. >>>> * Hereby configured values theoretically behave similar as all >>>> other injection points. They also can be qualified (the aspect of scopes, I >>>> did not yet have time to think about). The only difference is, that they >>>> are satisified using the configuration "system". >>>> * The configuration "source" itself could in the extreme simplest >>>> way be a Provider>. The CDI spec should not care about >>>> how this map is provided (XML, DB, overrides, etc). This still can be >>>> standardized later. As long as the ConfigurationSource SPI is defined, >>>> companies still can hook in the logic and level of configuration >>>> abstraction they need. >>>> * Of course, since not only Strings can be injected, we need some >>>> conversion or adapter logic as basically outlined in my blog. Also here we >>>> can add a simple SPI and let the details to the RI. >>>> >>>> Summarizing a >>>> >>>> * @Configured annotation >>>> * some kind of change event >>>> * a ConfigurationSource extends Provider> >>>> * a conversion mechanism from String to T. >>>> >>>> we get a full fledged configuration mechanism that leverages CDI. >>>> >>>> That would be my idea basically. WDYT? I will try to work that out in >>>> more details. Basically it should be implementable even with the CDI >>>> mechanism already in place with CDI 1.1. >>>> >>>> Best, >>>> Anatole >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves < >>>> antonio.goncalves at gmail.com>: >>>> One wise man* once said "EJB was a hype specification, we added too >>>> many things to it, it became bloated. The next hype specifications are >>>> JAX-RS and CDI, careful with them" >>>> >>>> Either we get this idea of "parts" right, or CDI will endup being >>>> bloated. >>>> >>>> Antonio >>>> >>>> >>>> *David Blevin >>>> >>>> >>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < >>>> antoine at sabot-durand.net> wrote: >>>> Hi all, >>>> >>>> You may have followed the rise and fall of the Java Config JSR ( >>>> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >>>> ). >>>> Anatole in CC was leading this initiative and I proposed him to join us >>>> and explore if some part of his late-JSR could be done in CDI. >>>> >>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >>>> related solution. If we achieve to have a majority of specs to integrate >>>> with CDI, our configuration solution would therefore become a configuration >>>> system for all spec based on CDI 2.0. >>>> >>>> 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. >>>> >>>> >>>> >>>> -- >>>> Antonio Goncalves >>>> Software architect, Java Champion and Pluralsight author >>>> >>>> Web site | Twitter< >>>> http://twitter.com/agoncal> | LinkedIn< >>>> http://www.linkedin.com/in/agoncal> | Pluralsight< >>>> http://pluralsight.com/training/Authors/Details/antonio-goncalves> | >>>> Paris JUG | Devoxx France>>> > >>>> >>>> _______________________________________________ >>>> 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. >>>> >>>> >>>> >>>> -- >>>> Anatole Tresch >>>> Java Lead Engineer, JSR Spec Lead >>>> Gl?rnischweg 10 >>>> CH - 8620 Wetzikon >>>> >>>> Switzerland, Europe Zurich, GMT+1 >>>> Twitter: @atsticks >>>> Blogs: http://javaremarkables.blogspot.ch/ >>>> Google: atsticks >>>> Mobile +41-76 344 62 79 >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: >>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>>> *************************************** >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. >>>> >>>> >>>> >>>> >>>> -- >>>> *Anatole Tresch* >>>> Java Lead Engineer, JSR Spec Lead >>>> Gl?rnischweg 10 >>>> CH - 8620 Wetzikon >>>> >>>> *Switzerland, Europe Zurich, GMT+1* >>>> *Twitter: @atsticks* >>>> *Blogs: **http://javaremarkables.blogspot.ch/ >>>> * >>>> >>>> *Google: atsticksMobile +41-76 344 62 79* >>>> >>>> _______________________________________________ >>>> 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. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. >>>> >>> >>> >>> >>> -- >>> *Anatole Tresch* >>> Java Lead Engineer, JSR Spec Lead >>> Gl?rnischweg 10 >>> CH - 8620 Wetzikon >>> >>> *Switzerland, Europe Zurich, GMT+1* >>> *Twitter: @atsticks* >>> *Blogs: **http://javaremarkables.blogspot.ch/ >>> * >>> >>> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* >>> >> >> > -- *Anatole Tresch* Java Lead Engineer, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140907/cd08b3ac/attachment-0001.html From werner.keil at gmail.com Sun Sep 7 17:39:51 2014 From: werner.keil at gmail.com (Werner Keil) Date: Sun, 7 Sep 2014 23:39:51 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Sounds like an argument for a CDI module rather than a separate JSR then?;-) On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch wrote: > I would not worry about CDI regarding licensing. Just the sentence was > that Oracle does not want to have more ALv2 in addition to what is already > there. So as long as we do things within CDI, no worries, I think. For new > EE JSRs nevertheless this is a BIG issue and should be clarified by the EC! > > > 2014-09-07 21:44 GMT+02:00 Werner Keil : > >> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under ALv2 >> as a dual-license, this was discussed by EC Members but both JCP EC and >> Oracle Legal/PMO seems fine with it, and CDI is already an essential >> building block to Java EE 6/7, hence used with Glassfish, too. I wasn't >> involved in these discussions, but given CDI is especially liberal and >> fully accepted by JCP formalities and license policies, I don't really see >> what the problem wss for Anatole's JSR attempt (though I know, both Oracle >> and other EC Members/companies don't always prefer this kind of >> licensing...;-) >> >> Werner >> >> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament >> wrote: >> >>> Ok, this mail has me more concerned than anything. Can you clarify this >>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. >>> >>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch >>> wrote: >>> >>>> Hi All >>>> >>>> unfortunately things seem quite complicated: >>>> >>>> - first of all,* similarities with Deltaspike are basically not >>>> accidental*. The concepts we developed in Credit Suisse are very >>>> similar to Deltaspike, though Deltaspike was not yet born at that time. >>>> Fortunately we ended up with a similar kind of solution. >>>> - *filtering still can be done.* My idea is to define some kind of >>>> "configuration provider", which then is dynamically asked for >>>> configuration. How the provider is internally organized, is completely >>>> transparent to CDI. This enables to have multi-layered, complex config >>>> solutions work the same (from a view point of CDI) like simple programmatic >>>> test configurations during unit tests. The config provider still can >>>> support filtering and dynamic resolution as commonly used in configuration >>>> systems. Similarly the format is basically also not fixed. Of course, would >>>> a reference implementation provide a set of functionalities, but I would >>>> definitively not define the exact configuration mechanism as part of the >>>> CDI (or even a EE config JSR). Another reason, beside complexity and time, >>>> is the fact that different companies handle, store and manage configuration >>>> differently, so a mechanism must be flexible enough to accommodate these, >>>> without adoption rate will be low. Furthermore this flexibility also keeps >>>> doors open for use cases we do not know yet. >>>> - Also we have to separate some basically *two types of >>>> configuration aspects:* >>>> - *application config *basically is injected into deployed >>>> components, but basically only can affect deployment to the extend it can >>>> be managed and injected by CDI. The basic architecture and design, how >>>> application servers to load and deploy are basically not affected. This >>>> type of configuration (mechanism) I see also as a possible addition to CDI, >>>> if we really fail to do something in another JSR. With CDI going for a more >>>> modular design, even basic configuration of CDI can be possible, given we >>>> have some kind of API, we can access during CDI initialization. >>>> - On the other side *deployment configuration *affects directly >>>> how the application server deploys the application. Configuration here >>>> would allow to define datasources, EJBs, transactional aspects, security, >>>> persistence, war and ear configurations etc. Basically everything you do as >>>> of today with some kind of XML file, or annotation. Hereby enabling more >>>> flexibility into the existing descriptors is relatively easy, but as >>>> mentioned by Mark, constraint. Adding more flexibility raises other subtle >>>> problems. Imagine a application module, e.g. a war, that defines everything >>>> it requires. There is no need to configure anything more on server side >>>> (with spring you can do this, with Java EE unfortunately not). But this has >>>> a severe consequence, it would make the application really portable in the >>>> sense, that it can be moved between different app servers (vendors) without >>>> any change (ideally). As a result commercial profits of some vendor >>>> companies may be affected. I think this is actually one of the key points, >>>> why things are getting so complicated in that area. >>>> - *Legal aspects* also were discussed. One of them is a possible >>>> legal clash of ALv2 with GPL. This is the case already within Glassfish, >>>> but one of the reasons, why ALv2 was not acceptable to Oracle's legal >>>> department. At the end we decided to use a BSD model. Even dual licensing >>>> BSD/ALv2 could theoretically be an option. If you would choose ALv2, Oracle >>>> will not include your RI into Glassfish, which is the RI for the EE >>>> Umbrella JSR, meaning your JSR will not be included into EE8. So what >>>> should we do? I don't have a good answer... >>>> >>>> So, I like to discuss configuration aspects here. Nevertheless if we >>>> decide to add config aspects, be aware that we might only (mainly) support >>>> application config, since everything else directly would impact other JSRs. >>>> And that is obviously quite similar to what Apache Deltaspike is all about >>>> ;-) >>>> >>>> Cheers, >>>> Anatole >>>> >>>> >>>> >>>> >>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : >>>> >>>>> Yes, the config group also was (obviously) looking at DeltaSpikes >>>>> config mechanism as well. >>>>> There were others who wanted to go more into the 'filtering' approach >>>>> as done on WebLogic servers (though not sure who else does that as well). >>>>> You know, having all the XML configs like WEB-INF/web.xml containing >>>>> placeholders and the real values only get placed in there at deployment >>>>> time. I personally find this approach a bit limited from a technical >>>>> perspective and it already didn't work out for me when using WebLogic (what >>>>> about changing a configured value after the deployment was done? What about >>>>> security? Having passwords in web.xml, unit testing, ...). >>>>> There are of course also other approaches which all might have strong >>>>> sides and would have needed to get discussed. >>>>> >>>>> But utterly the problem seems to have been legal reasons. We even >>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF project with >>>>> substantial support and participation from the JBoss, DeltaSpike and TomEE >>>>> communities. >>>>> >>>>> Anyway, the time will come when we will resurrect this effort. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> >>>>> On Sunday, 7 September 2014, 14:29, Werner Keil < >>>>> werner.keil at gmail.com> wrote: >>>>> >>>>> >>>>> >>>>> Yep, it contains a simple but extendable notion of ProjectStage, too;-) >>>>> >>>>> >>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament >>>>> wrote: >>>>> >>>>> Anatole, >>>>> >>>>> I'm wondering if some of your configuration description falls under >>>>> what was put together in DeltaSpike? >>>>> >>>>> http://deltaspike.apache.org/configuration.html >>>>> >>>>> John >>>>> >>>>> >>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch >>>>> wrote: >>>>> >>>>> Staging is not a question of xml or not xml (the "format" of config). >>>>> You can do staged config also using xml, or based on a database or json >>>>> config service. Staging as well as, more generally speaking, environment >>>>> dependent config is more like to select/filter the right config that >>>>> *targets *the current (runtime) environment. This might include >>>>> stages, but also many other aspects are feasible and common (server, tier, >>>>> ear, war, tenant ...). Since these aspects are per se very complex, it >>>>> might be advisable to leave them out of any spec (even a dedicated config >>>>> JSR would probably not be capable of covering these within the relatively >>>>> short EE timeframe)... >>>>> >>>>> >>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil : >>>>> >>>>> Jens/all, >>>>> >>>>> A sort of "staging" already was possible using CDI earlier, see >>>>> examples like this: >>>>> >>>>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >>>>> >>>>> DeltaSpike also includes type-safe staging that goes beyond the >>>>> primitive, hard-coded JSF enum. >>>>> >>>>> If that works without XML, while still allowing flexible configuration >>>>> for different stages or to add and "inject" additional stages maybe even >>>>> on a tenant basis (for Cloud scenarios) I could see something like that >>>>> work without XML. In the Multiconf project we managed to code everything in >>>>> Python, and similar to Puppet or Chef you can configure and deploy multiple >>>>> environments with it, Java EE, Spring or Play! several of them are >>>>> configured this way and it requires no XML (where the container needs such >>>>> files, the framework generates them;-) >>>>> >>>>> Werner >>>>> >>>>> On Fri, Sep 5, 2014 at 10:21 PM, >>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) >>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>>>> (Anatole Tresch (JIRA)) >>>>> 4. Re: With the end of Java Config... (Jens Schumann) >>>>> >>>>> ------------------------------ >>>>> >>>>> Message: 4 >>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >>>>> From: Jens Schumann >>>>> Subject: Re: [cdi-dev] With the end of Java Config... >>>>> To: Anatole Tresch , Antonio Goncalves >>>>> >>>>> Cc: cdi-dev >>>>> Message-ID: >>>>> Content-Type: text/plain; charset="windows-1252" >>>>> >>>>> I can confirm that this approach works very well. We are using a >>>>> similar approach a couple of years now, and I love the simplicity that >>>>> comes with portable extensions and @Producer methods. See our public >>>>> version here [1] (works since early CDI 1.0 days) . >>>>> >>>>> Instead of a @Inject + Qualifier we just use the qualifier @Property. >>>>> We support default values and type conversation for primitives and >>>>> everything that has a string based constructor. The property source can be >>>>> anything, from property files (default) to databases or xml files. For >>>>> examples see tests here [2]. >>>>> >>>>> Nevertheless I am not sure if this should be part of an future CDI >>>>> spec. My concerns include the bloat argument, of course. But the main >>>>> reason relates to the fact that we have almost everything in the current >>>>> CDI spec already. >>>>> >>>>> Right now I am quite happy with an custom portable extension that does >>>>> everything for me. At the time we implemented the extension we realised >>>>> that the "hard part" was writing an extension that links a qualified >>>>> "optional injection point" with an @Producer method while supporting code >>>>> based default values. Luckily I had Arne in my team who did that within a >>>>> few minutes. >>>>> >>>>> Because of this experience I would propose that we simplify extension >>>>> development such that "optional injection points" may be linked to >>>>> @Produces values easily. Additionally we have to solve a few more >>>>> integration issues (e.g. read-only DB access should be available during CDI >>>>> startup). Everything else should be provided by portable extensions (e.g. >>>>> via delta-spike) and documentation/howtos at cdi-spec.org. >>>>> >>>>> Jens >>>>> [1] >>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>>>> [2] >>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>>>> >>>>> Von: Anatole Tresch > >>>>> Datum: Friday 5 September 2014 21:22 >>>>> An: Antonio Goncalves >>>> antonio.goncalves at gmail.com>> >>>>> Cc: CDI-Dev > >>>>> Betreff: Re: [cdi-dev] With the end of Java Config... >>>>> >>>>> Hi all, >>>>> >>>>> I would not like to add an XML "bloated" mechanism as part of CDI 2.0. >>>>> Spontaneously I would propose a more CDI like things like: >>>>> >>>>> >>>>> * Adding a @Configured annotation (basically a qualifier). This >>>>> can be in addition to @Inject and would allow to inject "configured" values. >>>>> * Since configuration can change we may think of a (CDI) >>>>> event/reinject mechanism based on config changes. By default, this is >>>>> switched off and we can discuss how it would be activated, e.g. by an >>>>> additional flag settable with the @Configured annotation, or an additional >>>>> @Observable ConfigChangeEvent (similar to the Griffon framework), or both. >>>>> * Hereby configured values theoretically behave similar as all >>>>> other injection points. They also can be qualified (the aspect of scopes, I >>>>> did not yet have time to think about). The only difference is, that they >>>>> are satisified using the configuration "system". >>>>> * The configuration "source" itself could in the extreme simplest >>>>> way be a Provider>. The CDI spec should not care about >>>>> how this map is provided (XML, DB, overrides, etc). This still can be >>>>> standardized later. As long as the ConfigurationSource SPI is defined, >>>>> companies still can hook in the logic and level of configuration >>>>> abstraction they need. >>>>> * Of course, since not only Strings can be injected, we need some >>>>> conversion or adapter logic as basically outlined in my blog. Also here we >>>>> can add a simple SPI and let the details to the RI. >>>>> >>>>> Summarizing a >>>>> >>>>> * @Configured annotation >>>>> * some kind of change event >>>>> * a ConfigurationSource extends Provider> >>>>> * a conversion mechanism from String to T. >>>>> >>>>> we get a full fledged configuration mechanism that leverages CDI. >>>>> >>>>> That would be my idea basically. WDYT? I will try to work that out in >>>>> more details. Basically it should be implementable even with the CDI >>>>> mechanism already in place with CDI 1.1. >>>>> >>>>> Best, >>>>> Anatole >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves < >>>>> antonio.goncalves at gmail.com>: >>>>> One wise man* once said "EJB was a hype specification, we added too >>>>> many things to it, it became bloated. The next hype specifications are >>>>> JAX-RS and CDI, careful with them" >>>>> >>>>> Either we get this idea of "parts" right, or CDI will endup being >>>>> bloated. >>>>> >>>>> Antonio >>>>> >>>>> >>>>> *David Blevin >>>>> >>>>> >>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand < >>>>> antoine at sabot-durand.net> wrote: >>>>> Hi all, >>>>> >>>>> You may have followed the rise and fall of the Java Config JSR ( >>>>> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >>>>> ). >>>>> Anatole in CC was leading this initiative and I proposed him to join >>>>> us and explore if some part of his late-JSR could be done in CDI. >>>>> >>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >>>>> related solution. If we achieve to have a majority of specs to integrate >>>>> with CDI, our configuration solution would therefore become a configuration >>>>> system for all spec based on CDI 2.0. >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> -- >>>>> Antonio Goncalves >>>>> Software architect, Java Champion and Pluralsight author >>>>> >>>>> Web site | Twitter< >>>>> http://twitter.com/agoncal> | LinkedIn< >>>>> http://www.linkedin.com/in/agoncal> | Pluralsight< >>>>> http://pluralsight.com/training/Authors/Details/antonio-goncalves> | >>>>> Paris JUG | Devoxx France< >>>>> http://www.devoxx.fr> >>>>> >>>>> _______________________________________________ >>>>> 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. >>>>> >>>>> >>>>> >>>>> -- >>>>> Anatole Tresch >>>>> Java Lead Engineer, JSR Spec Lead >>>>> Gl?rnischweg 10 >>>>> CH - 8620 Wetzikon >>>>> >>>>> Switzerland, Europe Zurich, GMT+1 >>>>> Twitter: @atsticks >>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>>> Google: atsticks >>>>> Mobile +41-76 344 62 79 >>>>> -------------- next part -------------- >>>>> An HTML attachment was scrubbed... >>>>> URL: >>>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>>>> *************************************** >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Anatole Tresch* >>>>> Java Lead Engineer, JSR Spec Lead >>>>> Gl?rnischweg 10 >>>>> CH - 8620 Wetzikon >>>>> >>>>> *Switzerland, Europe Zurich, GMT+1* >>>>> *Twitter: @atsticks* >>>>> *Blogs: **http://javaremarkables.blogspot.ch/ >>>>> * >>>>> >>>>> *Google: atsticksMobile +41-76 344 62 79* >>>>> >>>>> _______________________________________________ >>>>> 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. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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. >>>>> >>>> >>>> >>>> >>>> -- >>>> *Anatole Tresch* >>>> Java Lead Engineer, JSR Spec Lead >>>> Gl?rnischweg 10 >>>> CH - 8620 Wetzikon >>>> >>>> *Switzerland, Europe Zurich, GMT+1* >>>> *Twitter: @atsticks* >>>> *Blogs: **http://javaremarkables.blogspot.ch/ >>>> * >>>> >>>> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* >>>> >>> >>> >> > > > -- > *Anatole Tresch* > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > * > > *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140907/49df6b67/attachment-0001.html From rmannibucau at gmail.com Sun Sep 7 18:10:41 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 8 Sep 2014 00:10:41 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: well sorry to pop in so late but here are my 2cts Config JSR is more about environment config IMHO and putting it in CDI doesn't make sense since more or more spec works without any other spec - CDI in our case. This mean CDI can't be the place but should just be the bridge for config JSR. Plus CDI config will surely highly be an application config first (beans.xml should be the place then) then environment config can be done at EE level (saying it has to support placeholders or any pre deployment processing). If you put something like ProjectStage in CDI it is great but then you have it in JSF, CDI and finally surely all specs...same as converters... Config should really be split in: 1) spec dependent config -> spec.xml 2) *common* config (a bit like javax.annotation) for environment and external configuration -> Config JSR wdyt? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-09-07 23:39 GMT+02:00 Werner Keil : > Sounds like an argument for a CDI module rather than a separate JSR then?;-) > > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch wrote: >> >> I would not worry about CDI regarding licensing. Just the sentence was >> that Oracle does not want to have more ALv2 in addition to what is already >> there. So as long as we do things within CDI, no worries, I think. For new >> EE JSRs nevertheless this is a BIG issue and should be clarified by the EC! >> >> >> 2014-09-07 21:44 GMT+02:00 Werner Keil : >>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under ALv2 >>> as a dual-license, this was discussed by EC Members but both JCP EC and >>> Oracle Legal/PMO seems fine with it, and CDI is already an essential >>> building block to Java EE 6/7, hence used with Glassfish, too. I wasn't >>> involved in these discussions, but given CDI is especially liberal and fully >>> accepted by JCP formalities and license policies, I don't really see what >>> the problem wss for Anatole's JSR attempt (though I know, both Oracle and >>> other EC Members/companies don't always prefer this kind of licensing...;-) >>> >>> Werner >>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament >>> wrote: >>>> >>>> Ok, this mail has me more concerned than anything. Can you clarify this >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. >>>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch >>>> wrote: >>>>> >>>>> Hi All >>>>> >>>>> unfortunately things seem quite complicated: >>>>> >>>>> first of all, similarities with Deltaspike are basically not >>>>> accidental. The concepts we developed in Credit Suisse are very similar to >>>>> Deltaspike, though Deltaspike was not yet born at that time. Fortunately we >>>>> ended up with a similar kind of solution. >>>>> filtering still can be done. My idea is to define some kind of >>>>> "configuration provider", which then is dynamically asked for configuration. >>>>> How the provider is internally organized, is completely transparent to CDI. >>>>> This enables to have multi-layered, complex config solutions work the same >>>>> (from a view point of CDI) like simple programmatic test configurations >>>>> during unit tests. The config provider still can support filtering and >>>>> dynamic resolution as commonly used in configuration systems. Similarly the >>>>> format is basically also not fixed. Of course, would a reference >>>>> implementation provide a set of functionalities, but I would definitively >>>>> not define the exact configuration mechanism as part of the CDI (or even a >>>>> EE config JSR). Another reason, beside complexity and time, is the fact that >>>>> different companies handle, store and manage configuration differently, so a >>>>> mechanism must be flexible enough to accommodate these, without adoption >>>>> rate will be low. Furthermore this flexibility also keeps doors open for use >>>>> cases we do not know yet. >>>>> Also we have to separate some basically two types of configuration >>>>> aspects: >>>>> >>>>> application config basically is injected into deployed components, but >>>>> basically only can affect deployment to the extend it can be managed and >>>>> injected by CDI. The basic architecture and design, how application servers >>>>> to load and deploy are basically not affected. This type of configuration >>>>> (mechanism) I see also as a possible addition to CDI, if we really fail to >>>>> do something in another JSR. With CDI going for a more modular design, even >>>>> basic configuration of CDI can be possible, given we have some kind of API, >>>>> we can access during CDI initialization. >>>>> On the other side deployment configuration affects directly how the >>>>> application server deploys the application. Configuration here would allow >>>>> to define datasources, EJBs, transactional aspects, security, persistence, >>>>> war and ear configurations etc. Basically everything you do as of today with >>>>> some kind of XML file, or annotation. Hereby enabling more flexibility into >>>>> the existing descriptors is relatively easy, but as mentioned by Mark, >>>>> constraint. Adding more flexibility raises other subtle problems. Imagine a >>>>> application module, e.g. a war, that defines everything it requires. There >>>>> is no need to configure anything more on server side (with spring you can do >>>>> this, with Java EE unfortunately not). But this has a severe consequence, it >>>>> would make the application really portable in the sense, that it can be >>>>> moved between different app servers (vendors) without any change (ideally). >>>>> As a result commercial profits of some vendor companies may be affected. I >>>>> think this is actually one of the key points, why things are getting so >>>>> complicated in that area. >>>>> >>>>> Legal aspects also were discussed. One of them is a possible legal >>>>> clash of ALv2 with GPL. This is the case already within Glassfish, but one >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal department. At >>>>> the end we decided to use a BSD model. Even dual licensing BSD/ALv2 could >>>>> theoretically be an option. If you would choose ALv2, Oracle will not >>>>> include your RI into Glassfish, which is the RI for the EE Umbrella JSR, >>>>> meaning your JSR will not be included into EE8. So what should we do? I >>>>> don't have a good answer... >>>>> >>>>> So, I like to discuss configuration aspects here. Nevertheless if we >>>>> decide to add config aspects, be aware that we might only (mainly) support >>>>> application config, since everything else directly would impact other JSRs. >>>>> And that is obviously quite similar to what Apache Deltaspike is all about >>>>> ;-) >>>>> >>>>> Cheers, >>>>> Anatole >>>>> >>>>> >>>>> >>>>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : >>>>>> >>>>>> Yes, the config group also was (obviously) looking at DeltaSpikes >>>>>> config mechanism as well. >>>>>> There were others who wanted to go more into the 'filtering' approach >>>>>> as done on WebLogic servers (though not sure who else does that as well). >>>>>> You know, having all the XML configs like WEB-INF/web.xml containing >>>>>> placeholders and the real values only get placed in there at deployment >>>>>> time. I personally find this approach a bit limited from a technical >>>>>> perspective and it already didn't work out for me when using WebLogic (what >>>>>> about changing a configured value after the deployment was done? What about >>>>>> security? Having passwords in web.xml, unit testing, ...). >>>>>> There are of course also other approaches which all might have strong >>>>>> sides and would have needed to get discussed. >>>>>> >>>>>> But utterly the problem seems to have been legal reasons. We even >>>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF project with >>>>>> substantial support and participation from the JBoss, DeltaSpike and TomEE >>>>>> communities. >>>>>> >>>>>> Anyway, the time will come when we will resurrect this effort. >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Yep, it contains a simple but extendable notion of ProjectStage, >>>>>> too;-) >>>>>> >>>>>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament >>>>>> wrote: >>>>>> >>>>>> Anatole, >>>>>> >>>>>> I'm wondering if some of your configuration description falls under >>>>>> what was put together in DeltaSpike? >>>>>> >>>>>> http://deltaspike.apache.org/configuration.html >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch >>>>>> wrote: >>>>>> >>>>>> Staging is not a question of xml or not xml (the "format" of config). >>>>>> You can do staged config also using xml, or based on a database or json >>>>>> config service. Staging as well as, more generally speaking, environment >>>>>> dependent config is more like to select/filter the right config that targets >>>>>> the current (runtime) environment. This might include stages, but also many >>>>>> other aspects are feasible and common (server, tier, ear, war, tenant ...). >>>>>> Since these aspects are per se very complex, it might be advisable to leave >>>>>> them out of any spec (even a dedicated config JSR would probably not be >>>>>> capable of covering these within the relatively short EE timeframe)... >>>>>> >>>>>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil : >>>>>> >>>>>> Jens/all, >>>>>> >>>>>> A sort of "staging" already was possible using CDI earlier, see >>>>>> examples like this: >>>>>> >>>>>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >>>>>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond the >>>>>> primitive, hard-coded JSF enum. >>>>>> >>>>>> If that works without XML, while still allowing flexible configuration >>>>>> for different stages or to add and "inject" additional stages maybe even on >>>>>> a tenant basis (for Cloud scenarios) I could see something like that work >>>>>> without XML. In the Multiconf project we managed to code everything in >>>>>> Python, and similar to Puppet or Chef you can configure and deploy multiple >>>>>> environments with it, Java EE, Spring or Play! several of them are >>>>>> configured this way and it requires no XML (where the container needs such >>>>>> files, the framework generates them;-) >>>>>> >>>>>> Werner >>>>>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch) >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>>>>> (Anatole Tresch (JIRA)) >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) >>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> Message: 4 >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >>>>>> From: Jens Schumann >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... >>>>>> To: Anatole Tresch , Antonio Goncalves >>>>>> >>>>>> Cc: cdi-dev >>>>>> Message-ID: >>>>>> Content-Type: text/plain; charset="windows-1252" >>>>>> >>>>>> I can confirm that this approach works very well. We are using a >>>>>> similar approach a couple of years now, and I love the simplicity that comes >>>>>> with portable extensions and @Producer methods. See our public version here >>>>>> [1] (works since early CDI 1.0 days) . >>>>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier @Property. >>>>>> We support default values and type conversation for primitives and >>>>>> everything that has a string based constructor. The property source can be >>>>>> anything, from property files (default) to databases or xml files. For >>>>>> examples see tests here [2]. >>>>>> >>>>>> Nevertheless I am not sure if this should be part of an future CDI >>>>>> spec. My concerns include the bloat argument, of course. But the main reason >>>>>> relates to the fact that we have almost everything in the current CDI spec >>>>>> already. >>>>>> >>>>>> Right now I am quite happy with an custom portable extension that does >>>>>> everything for me. At the time we implemented the extension we realised that >>>>>> the "hard part" was writing an extension that links a qualified "optional >>>>>> injection point" with an @Producer method while supporting code based >>>>>> default values. Luckily I had Arne in my team who did that within a few >>>>>> minutes. >>>>>> >>>>>> Because of this experience I would propose that we simplify extension >>>>>> development such that "optional injection points" may be linked to @Produces >>>>>> values easily. Additionally we have to solve a few more integration issues >>>>>> (e.g. read-only DB access should be available during CDI startup). >>>>>> Everything else should be provided by portable extensions (e.g. via >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. >>>>>> >>>>>> Jens >>>>>> [1] >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>>>>> [2] >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>>>>> >>>>>> Von: Anatole Tresch > >>>>>> Datum: Friday 5 September 2014 21:22 >>>>>> An: Antonio Goncalves >>>>>> > >>>>>> Cc: CDI-Dev > >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I would not like to add an XML "bloated" mechanism as part of CDI 2.0. >>>>>> Spontaneously I would propose a more CDI like things like: >>>>>> >>>>>> >>>>>> * Adding a @Configured annotation (basically a qualifier). This >>>>>> can be in addition to @Inject and would allow to inject "configured" values. >>>>>> * Since configuration can change we may think of a (CDI) >>>>>> event/reinject mechanism based on config changes. By default, this is >>>>>> switched off and we can discuss how it would be activated, e.g. by an >>>>>> additional flag settable with the @Configured annotation, or an additional >>>>>> @Observable ConfigChangeEvent (similar to the Griffon framework), or both. >>>>>> * Hereby configured values theoretically behave similar as all >>>>>> other injection points. They also can be qualified (the aspect of scopes, I >>>>>> did not yet have time to think about). The only difference is, that they are >>>>>> satisified using the configuration "system". >>>>>> * The configuration "source" itself could in the extreme simplest >>>>>> way be a Provider>. The CDI spec should not care about >>>>>> how this map is provided (XML, DB, overrides, etc). This still can be >>>>>> standardized later. As long as the ConfigurationSource SPI is defined, >>>>>> companies still can hook in the logic and level of configuration abstraction >>>>>> they need. >>>>>> * Of course, since not only Strings can be injected, we need some >>>>>> conversion or adapter logic as basically outlined in my blog. Also here we >>>>>> can add a simple SPI and let the details to the RI. >>>>>> >>>>>> Summarizing a >>>>>> >>>>>> * @Configured annotation >>>>>> * some kind of change event >>>>>> * a ConfigurationSource extends Provider> >>>>>> * a conversion mechanism from String to T. >>>>>> >>>>>> we get a full fledged configuration mechanism that leverages CDI. >>>>>> >>>>>> That would be my idea basically. WDYT? I will try to work that out in >>>>>> more details. Basically it should be implementable even with the CDI >>>>>> mechanism already in place with CDI 1.1. >>>>>> >>>>>> Best, >>>>>> Anatole >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >>>>>> >: >>>>>> One wise man* once said "EJB was a hype specification, we added too >>>>>> many things to it, it became bloated. The next hype specifications are >>>>>> JAX-RS and CDI, careful with them" >>>>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup being >>>>>> bloated. >>>>>> >>>>>> Antonio >>>>>> >>>>>> >>>>>> *David Blevin >>>>>> >>>>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand >>>>>> > wrote: >>>>>> Hi all, >>>>>> >>>>>> You may have followed the rise and fall of the Java Config JSR >>>>>> (http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html). >>>>>> Anatole in CC was leading this initiative and I proposed him to join >>>>>> us and explore if some part of his late-JSR could be done in CDI. >>>>>> >>>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >>>>>> related solution. If we achieve to have a majority of specs to integrate >>>>>> with CDI, our configuration solution would therefore become a configuration >>>>>> system for all spec based on CDI 2.0. >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Antonio Goncalves >>>>>> Software architect, Java Champion and Pluralsight author >>>>>> >>>>>> Web site | >>>>>> Twitter | >>>>>> LinkedIn | >>>>>> Pluralsight >>>>>> | Paris JUG | Devoxx France >>>>>> >>>>>> _______________________________________________ >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Anatole Tresch >>>>>> Java Lead Engineer, JSR Spec Lead >>>>>> Gl?rnischweg 10 >>>>>> CH - 8620 Wetzikon >>>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>>>>> Twitter: @atsticks >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>>>> Google: atsticks >>>>>> Mobile +41-76 344 62 79 >>>>>> -------------- next part -------------- >>>>>> An HTML attachment was scrubbed... >>>>>> URL: >>>>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>>>>> *************************************** >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Anatole Tresch >>>>>> Java Lead Engineer, JSR Spec Lead >>>>>> Gl?rnischweg 10 >>>>>> CH - 8620 Wetzikon >>>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>>>>> Twitter: @atsticks >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>>>> Google: atsticks >>>>>> Mobile +41-76 344 62 79 >>>>>> >>>>>> _______________________________________________ >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Anatole Tresch >>>>> Java Lead Engineer, JSR Spec Lead >>>>> Gl?rnischweg 10 >>>>> CH - 8620 Wetzikon >>>>> >>>>> Switzerland, Europe Zurich, GMT+1 >>>>> Twitter: @atsticks >>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>>> Google: atsticks >>>>> Mobile +41-76 344 62 79 >>>> >>>> >>> >> >> >> >> -- >> Anatole Tresch >> Java Lead Engineer, JSR Spec Lead >> Gl?rnischweg 10 >> CH - 8620 Wetzikon >> >> Switzerland, Europe Zurich, GMT+1 >> Twitter: @atsticks >> Blogs: http://javaremarkables.blogspot.ch/ >> Google: atsticks >> Mobile +41-76 344 62 79 > > > > _______________________________________________ > 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 atsticks at gmail.com Sun Sep 7 19:00:52 2014 From: atsticks at gmail.com (Anatole Tresch) Date: Mon, 8 Sep 2014 01:00:52 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Hi Romain just a few remarks inline... Summarizing 1) injection of values, reinjection, feedback on config changes can all be done with already existing features (producers, extensions). 2) configuring/bootstrapping CDI itself, e.g. configuration, is targeted with CDI 2.0 (see spec failing) So basically we could try to look if there is enough interest to standardize configuration in a more general way. For deployment aspects we need an EE JSR, for the rest, another SE standard may be an option as well... tbd... -Anatole 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : > well sorry to pop in so late but here are my 2cts > ?easy ;)? > Config JSR is more about environment config IMHO and putting it in CDI > doesn't make sense since more or more spec works without any other > spec - CDI in our case. ?CDI even with some config mechanism added would still work "standalone".? > This mean CDI can't be the place but should > just be the bridge for config JSR. ?As I suggested as well.? > Plus CDI config will surely highly > be an application config first (beans.xml should be the place then) > ?Yes, app config, but beware people of writing config into beans.xml. That is definitively in most cases not what you want.? CDI should not define, where and how config is located and formatted. CDI should provide a SPI, where config providers can publish the configured values, so it can be injected wherever needed. E.g. some kind of producer, that can provide multiple objects to be injected and can benefit from some kind of callback mechanism would be sufficient... > then environment config can be done at EE level (saying it has to > support placeholders or any pre deployment processing). > ?Config is much more complex. There is no clear border what is environment config or environment dependent and what not. This depends on what kind of application you have deployed. As an example the email address, where you send error messages, can be different depenending on the stage/environment, but this is not EE related config entry. Also what an environment is, is not a thing that you can define completely. So I agree not to add this complexities to CDI, I would hide them between some kind of "config provider", as mentioned above.? CDI does not need to know if the config provided is environment dependent or not, its just what is visible at a current runtime state... > If you put something like ProjectStage in CDI it is great but then you > have it in JSF, CDI and finally surely all specs...same as > converters... > ?That was originally the idea, when doing a EE config JSR, but without such standard. I agree, CDI is not the place to define them. > Config should really be split in: > 1) spec dependent config -> spec.xml > 2) *common* config (a bit like javax.annotation) for environment and > external configuration -> Config JSR > ?Not 100% sure, if a get the point here... 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : > well sorry to pop in so late but here are my 2cts > > Config JSR is more about environment config IMHO and putting it in CDI > doesn't make sense since more or more spec works without any other > spec - CDI in our case. This mean CDI can't be the place but should > just be the bridge for config JSR. Plus CDI config will surely highly > be an application config first (beans.xml should be the place then) > then environment config can be done at EE level (saying it has to > support placeholders or any pre deployment processing). > > If you put something like ProjectStage in CDI it is great but then you > have it in JSF, CDI and finally surely all specs...same as > converters... > > Config should really be split in: > 1) spec dependent config -> spec.xml > 2) *common* config (a bit like javax.annotation) for environment and > external configuration -> Config JSR > > wdyt? > > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > 2014-09-07 23:39 GMT+02:00 Werner Keil : > > Sounds like an argument for a CDI module rather than a separate JSR > then?;-) > > > > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch > wrote: > >> > >> I would not worry about CDI regarding licensing. Just the sentence was > >> that Oracle does not want to have more ALv2 in addition to what is > already > >> there. So as long as we do things within CDI, no worries, I think. For > new > >> EE JSRs nevertheless this is a BIG issue and should be clarified by the > EC! > >> > >> > >> 2014-09-07 21:44 GMT+02:00 Werner Keil : > >>> > >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under ALv2 > >>> as a dual-license, this was discussed by EC Members but both JCP EC and > >>> Oracle Legal/PMO seems fine with it, and CDI is already an essential > >>> building block to Java EE 6/7, hence used with Glassfish, too. I wasn't > >>> involved in these discussions, but given CDI is especially liberal and > fully > >>> accepted by JCP formalities and license policies, I don't really see > what > >>> the problem wss for Anatole's JSR attempt (though I know, both Oracle > and > >>> other EC Members/companies don't always prefer this kind of > licensing...;-) > >>> > >>> Werner > >>> > >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament > >>> wrote: > >>>> > >>>> Ok, this mail has me more concerned than anything. Can you clarify > this > >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. > >>>> > >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch > >>>> wrote: > >>>>> > >>>>> Hi All > >>>>> > >>>>> unfortunately things seem quite complicated: > >>>>> > >>>>> first of all, similarities with Deltaspike are basically not > >>>>> accidental. The concepts we developed in Credit Suisse are very > similar to > >>>>> Deltaspike, though Deltaspike was not yet born at that time. > Fortunately we > >>>>> ended up with a similar kind of solution. > >>>>> filtering still can be done. My idea is to define some kind of > >>>>> "configuration provider", which then is dynamically asked for > configuration. > >>>>> How the provider is internally organized, is completely transparent > to CDI. > >>>>> This enables to have multi-layered, complex config solutions work > the same > >>>>> (from a view point of CDI) like simple programmatic test > configurations > >>>>> during unit tests. The config provider still can support filtering > and > >>>>> dynamic resolution as commonly used in configuration systems. > Similarly the > >>>>> format is basically also not fixed. Of course, would a reference > >>>>> implementation provide a set of functionalities, but I would > definitively > >>>>> not define the exact configuration mechanism as part of the CDI (or > even a > >>>>> EE config JSR). Another reason, beside complexity and time, is the > fact that > >>>>> different companies handle, store and manage configuration > differently, so a > >>>>> mechanism must be flexible enough to accommodate these, without > adoption > >>>>> rate will be low. Furthermore this flexibility also keeps doors open > for use > >>>>> cases we do not know yet. > >>>>> Also we have to separate some basically two types of configuration > >>>>> aspects: > >>>>> > >>>>> application config basically is injected into deployed components, > but > >>>>> basically only can affect deployment to the extend it can be managed > and > >>>>> injected by CDI. The basic architecture and design, how application > servers > >>>>> to load and deploy are basically not affected. This type of > configuration > >>>>> (mechanism) I see also as a possible addition to CDI, if we really > fail to > >>>>> do something in another JSR. With CDI going for a more modular > design, even > >>>>> basic configuration of CDI can be possible, given we have some kind > of API, > >>>>> we can access during CDI initialization. > >>>>> On the other side deployment configuration affects directly how the > >>>>> application server deploys the application. Configuration here would > allow > >>>>> to define datasources, EJBs, transactional aspects, security, > persistence, > >>>>> war and ear configurations etc. Basically everything you do as of > today with > >>>>> some kind of XML file, or annotation. Hereby enabling more > flexibility into > >>>>> the existing descriptors is relatively easy, but as mentioned by > Mark, > >>>>> constraint. Adding more flexibility raises other subtle problems. > Imagine a > >>>>> application module, e.g. a war, that defines everything it requires. > There > >>>>> is no need to configure anything more on server side (with spring > you can do > >>>>> this, with Java EE unfortunately not). But this has a severe > consequence, it > >>>>> would make the application really portable in the sense, that it can > be > >>>>> moved between different app servers (vendors) without any change > (ideally). > >>>>> As a result commercial profits of some vendor companies may be > affected. I > >>>>> think this is actually one of the key points, why things are getting > so > >>>>> complicated in that area. > >>>>> > >>>>> Legal aspects also were discussed. One of them is a possible legal > >>>>> clash of ALv2 with GPL. This is the case already within Glassfish, > but one > >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal > department. At > >>>>> the end we decided to use a BSD model. Even dual licensing BSD/ALv2 > could > >>>>> theoretically be an option. If you would choose ALv2, Oracle will not > >>>>> include your RI into Glassfish, which is the RI for the EE Umbrella > JSR, > >>>>> meaning your JSR will not be included into EE8. So what should we > do? I > >>>>> don't have a good answer... > >>>>> > >>>>> So, I like to discuss configuration aspects here. Nevertheless if we > >>>>> decide to add config aspects, be aware that we might only (mainly) > support > >>>>> application config, since everything else directly would impact > other JSRs. > >>>>> And that is obviously quite similar to what Apache Deltaspike is all > about > >>>>> ;-) > >>>>> > >>>>> Cheers, > >>>>> Anatole > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : > >>>>>> > >>>>>> Yes, the config group also was (obviously) looking at DeltaSpikes > >>>>>> config mechanism as well. > >>>>>> There were others who wanted to go more into the 'filtering' > approach > >>>>>> as done on WebLogic servers (though not sure who else does that as > well). > >>>>>> You know, having all the XML configs like WEB-INF/web.xml containing > >>>>>> placeholders and the real values only get placed in there at > deployment > >>>>>> time. I personally find this approach a bit limited from a technical > >>>>>> perspective and it already didn't work out for me when using > WebLogic (what > >>>>>> about changing a configured value after the deployment was done? > What about > >>>>>> security? Having passwords in web.xml, unit testing, ...). > >>>>>> There are of course also other approaches which all might have > strong > >>>>>> sides and would have needed to get discussed. > >>>>>> > >>>>>> But utterly the problem seems to have been legal reasons. We even > >>>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF > project with > >>>>>> substantial support and participation from the JBoss, DeltaSpike > and TomEE > >>>>>> communities. > >>>>>> > >>>>>> Anyway, the time will come when we will resurrect this effort. > >>>>>> > >>>>>> LieGrue, > >>>>>> strub > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil > >>>>>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> Yep, it contains a simple but extendable notion of ProjectStage, > >>>>>> too;-) > >>>>>> > >>>>>> > >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament < > john.d.ament at gmail.com> > >>>>>> wrote: > >>>>>> > >>>>>> Anatole, > >>>>>> > >>>>>> I'm wondering if some of your configuration description falls under > >>>>>> what was put together in DeltaSpike? > >>>>>> > >>>>>> http://deltaspike.apache.org/configuration.html > >>>>>> > >>>>>> John > >>>>>> > >>>>>> > >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch > >>>>>> wrote: > >>>>>> > >>>>>> Staging is not a question of xml or not xml (the "format" of > config). > >>>>>> You can do staged config also using xml, or based on a database or > json > >>>>>> config service. Staging as well as, more generally speaking, > environment > >>>>>> dependent config is more like to select/filter the right config > that targets > >>>>>> the current (runtime) environment. This might include stages, but > also many > >>>>>> other aspects are feasible and common (server, tier, ear, war, > tenant ...). > >>>>>> Since these aspects are per se very complex, it might be advisable > to leave > >>>>>> them out of any spec (even a dedicated config JSR would probably > not be > >>>>>> capable of covering these within the relatively short EE > timeframe)... > >>>>>> > >>>>>> > >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil : > >>>>>> > >>>>>> Jens/all, > >>>>>> > >>>>>> A sort of "staging" already was possible using CDI earlier, see > >>>>>> examples like this: > >>>>>> > >>>>>> > http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war > >>>>>> > >>>>>> DeltaSpike also includes type-safe staging that goes beyond the > >>>>>> primitive, hard-coded JSF enum. > >>>>>> > >>>>>> If that works without XML, while still allowing flexible > configuration > >>>>>> for different stages or to add and "inject" additional stages > maybe even on > >>>>>> a tenant basis (for Cloud scenarios) I could see something like > that work > >>>>>> without XML. In the Multiconf project we managed to code everything > in > >>>>>> Python, and similar to Puppet or Chef you can configure and deploy > multiple > >>>>>> environments with it, Java EE, Spring or Play! several of them are > >>>>>> configured this way and it requires no XML (where the container > needs such > >>>>>> files, the framework generates them;-) > >>>>>> > >>>>>> Werner > >>>>>> > >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, > >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole > Tresch) > >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) > >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition > >>>>>> (Anatole Tresch (JIRA)) > >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) > >>>>>> > >>>>>> ------------------------------ > >>>>>> > >>>>>> Message: 4 > >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 > >>>>>> From: Jens Schumann > >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... > >>>>>> To: Anatole Tresch , Antonio Goncalves > >>>>>> > >>>>>> Cc: cdi-dev > >>>>>> Message-ID: > >>>>>> Content-Type: text/plain; charset="windows-1252" > >>>>>> > >>>>>> I can confirm that this approach works very well. We are using a > >>>>>> similar approach a couple of years now, and I love the simplicity > that comes > >>>>>> with portable extensions and @Producer methods. See our public > version here > >>>>>> [1] (works since early CDI 1.0 days) . > >>>>>> > >>>>>> Instead of a @Inject + Qualifier we just use the qualifier > @Property. > >>>>>> We support default values and type conversation for primitives and > >>>>>> everything that has a string based constructor. The property source > can be > >>>>>> anything, from property files (default) to databases or xml files. > For > >>>>>> examples see tests here [2]. > >>>>>> > >>>>>> Nevertheless I am not sure if this should be part of an future CDI > >>>>>> spec. My concerns include the bloat argument, of course. But the > main reason > >>>>>> relates to the fact that we have almost everything in the current > CDI spec > >>>>>> already. > >>>>>> > >>>>>> Right now I am quite happy with an custom portable extension that > does > >>>>>> everything for me. At the time we implemented the extension we > realised that > >>>>>> the "hard part" was writing an extension that links a qualified > "optional > >>>>>> injection point" with an @Producer method while supporting code > based > >>>>>> default values. Luckily I had Arne in my team who did that within a > few > >>>>>> minutes. > >>>>>> > >>>>>> Because of this experience I would propose that we simplify > extension > >>>>>> development such that "optional injection points" may be linked to > @Produces > >>>>>> values easily. Additionally we have to solve a few more integration > issues > >>>>>> (e.g. read-only DB access should be available during CDI startup). > >>>>>> Everything else should be provided by portable extensions (e.g. via > >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. > >>>>>> > >>>>>> Jens > >>>>>> [1] > >>>>>> > https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property > >>>>>> [2] > >>>>>> > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property > >>>>>> > >>>>>> Von: Anatole Tresch > > >>>>>> Datum: Friday 5 September 2014 21:22 > >>>>>> An: Antonio Goncalves > >>>>>> > > >>>>>> Cc: CDI-Dev >> > >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I would not like to add an XML "bloated" mechanism as part of CDI > 2.0. > >>>>>> Spontaneously I would propose a more CDI like things like: > >>>>>> > >>>>>> > >>>>>> * Adding a @Configured annotation (basically a qualifier). This > >>>>>> can be in addition to @Inject and would allow to inject > "configured" values. > >>>>>> * Since configuration can change we may think of a (CDI) > >>>>>> event/reinject mechanism based on config changes. By default, this > is > >>>>>> switched off and we can discuss how it would be activated, e.g. by > an > >>>>>> additional flag settable with the @Configured annotation, or an > additional > >>>>>> @Observable ConfigChangeEvent (similar to the Griffon framework), > or both. > >>>>>> * Hereby configured values theoretically behave similar as all > >>>>>> other injection points. They also can be qualified (the aspect of > scopes, I > >>>>>> did not yet have time to think about). The only difference is, that > they are > >>>>>> satisified using the configuration "system". > >>>>>> * The configuration "source" itself could in the extreme > simplest > >>>>>> way be a Provider>. The CDI spec should not care > about > >>>>>> how this map is provided (XML, DB, overrides, etc). This still can > be > >>>>>> standardized later. As long as the ConfigurationSource SPI is > defined, > >>>>>> companies still can hook in the logic and level of configuration > abstraction > >>>>>> they need. > >>>>>> * Of course, since not only Strings can be injected, we need > some > >>>>>> conversion or adapter logic as basically outlined in my blog. Also > here we > >>>>>> can add a simple SPI and let the details to the RI. > >>>>>> > >>>>>> Summarizing a > >>>>>> > >>>>>> * @Configured annotation > >>>>>> * some kind of change event > >>>>>> * a ConfigurationSource extends Provider> > >>>>>> * a conversion mechanism from String to T. > >>>>>> > >>>>>> we get a full fledged configuration mechanism that leverages CDI. > >>>>>> > >>>>>> That would be my idea basically. WDYT? I will try to work that out > in > >>>>>> more details. Basically it should be implementable even with the CDI > >>>>>> mechanism already in place with CDI 1.1. > >>>>>> > >>>>>> Best, > >>>>>> Anatole > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves > >>>>>> >: > >>>>>> One wise man* once said "EJB was a hype specification, we added too > >>>>>> many things to it, it became bloated. The next hype specifications > are > >>>>>> JAX-RS and CDI, careful with them" > >>>>>> > >>>>>> Either we get this idea of "parts" right, or CDI will endup being > >>>>>> bloated. > >>>>>> > >>>>>> Antonio > >>>>>> > >>>>>> > >>>>>> *David Blevin > >>>>>> > >>>>>> > >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand > >>>>>> > wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> You may have followed the rise and fall of the Java Config JSR > >>>>>> ( > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > ). > >>>>>> Anatole in CC was leading this initiative and I proposed him to join > >>>>>> us and explore if some part of his late-JSR could be done in CDI. > >>>>>> > >>>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or > >>>>>> related solution. If we achieve to have a majority of specs to > integrate > >>>>>> with CDI, our configuration solution would therefore become a > configuration > >>>>>> system for all spec based on CDI 2.0. > >>>>>> > >>>>>> 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. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Antonio Goncalves > >>>>>> Software architect, Java Champion and Pluralsight author > >>>>>> > >>>>>> Web site | > >>>>>> Twitter | > >>>>>> LinkedIn | > >>>>>> Pluralsight< > http://pluralsight.com/training/Authors/Details/antonio-goncalves> > >>>>>> | Paris JUG | Devoxx France< > http://www.devoxx.fr> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Anatole Tresch > >>>>>> Java Lead Engineer, JSR Spec Lead > >>>>>> Gl?rnischweg 10 > >>>>>> CH - 8620 Wetzikon > >>>>>> > >>>>>> Switzerland, Europe Zurich, GMT+1 > >>>>>> Twitter: @atsticks > >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>>> Google: atsticks > >>>>>> Mobile +41-76 344 62 79 > >>>>>> -------------- next part -------------- > >>>>>> An HTML attachment was scrubbed... > >>>>>> URL: > >>>>>> > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 > >>>>>> *************************************** > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Anatole Tresch > >>>>>> Java Lead Engineer, JSR Spec Lead > >>>>>> Gl?rnischweg 10 > >>>>>> CH - 8620 Wetzikon > >>>>>> > >>>>>> Switzerland, Europe Zurich, GMT+1 > >>>>>> Twitter: @atsticks > >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>>> Google: atsticks > >>>>>> Mobile +41-76 344 62 79 > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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. > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Anatole Tresch > >>>>> Java Lead Engineer, JSR Spec Lead > >>>>> Gl?rnischweg 10 > >>>>> CH - 8620 Wetzikon > >>>>> > >>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> Twitter: @atsticks > >>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> Google: atsticks > >>>>> Mobile +41-76 344 62 79 > >>>> > >>>> > >>> > >> > >> > >> > >> -- > >> Anatole Tresch > >> Java Lead Engineer, JSR Spec Lead > >> Gl?rnischweg 10 > >> CH - 8620 Wetzikon > >> > >> Switzerland, Europe Zurich, GMT+1 > >> Twitter: @atsticks > >> Blogs: http://javaremarkables.blogspot.ch/ > >> Google: atsticks > >> Mobile +41-76 344 62 79 > > > > > > > > _______________________________________________ > > 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. > -- *Anatole Tresch* Java Lead Engineer, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/3fce608f/attachment-0001.html From rmannibucau at gmail.com Mon Sep 8 01:03:44 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 8 Sep 2014 07:03:44 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Hmm I see config jsr as a jse spec which would allow EE injections in config components in EE containers (exactly like jbatch). This way it can be used without any container or with any container easily. Only limit will be to not do something cdi/known containers will not support I think. Not sure EE side is needed today, a lot can already be done without it and it can be enhanced later adding some integration words. Le 8 sept. 2014 00:01, "Anatole Tresch" a ?crit : > Hi Romain > > just a few remarks inline... > > Summarizing > 1) injection of values, reinjection, feedback on config changes can all be > done with already existing features (producers, extensions). > 2) configuring/bootstrapping CDI itself, e.g. configuration, is targeted > with CDI 2.0 (see spec failing) > > So basically we could try to look if there is enough interest to > standardize configuration in a more general way. For deployment aspects we > need an EE JSR, for the rest, another SE standard may be an option as > well... tbd... > > -Anatole > > > 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : > >> well sorry to pop in so late but here are my 2cts >> > ?easy ;)? > > >> Config JSR is more about environment config IMHO and putting it in CDI >> doesn't make sense since more or more spec works without any other >> spec - CDI in our case. > > ?CDI even with some config mechanism added would still work "standalone".? > > > >> This mean CDI can't be the place but should >> just be the bridge for config JSR. > > ?As I suggested as well.? > > > >> Plus CDI config will surely highly >> be an application config first (beans.xml should be the place then) >> > ?Yes, app config, but beware people of writing config into beans.xml. That > is definitively in most cases not what you want.? CDI should not define, > where and how config is located and formatted. CDI should provide a SPI, > where config providers can publish the configured values, so it can be > injected wherever needed. E.g. some kind of producer, that can provide > multiple objects to be injected and can benefit from some kind of callback > mechanism would be sufficient... > > >> then environment config can be done at EE level (saying it has to >> support placeholders or any pre deployment processing). >> > ?Config is much more complex. There is no clear border what is environment > config or environment dependent and what not. This depends on what kind of > application you have deployed. As an example the email address, where you > send error messages, can be different depenending on the stage/environment, > but this is not EE related config entry. Also what an environment is, is > not a thing that you can define completely. So I agree not to add this > complexities to CDI, I would hide them between some kind of "config > provider", as mentioned above.? CDI does not need to know if the config > provided is environment dependent or not, its just what is visible at a > current runtime state... > > >> If you put something like ProjectStage in CDI it is great but then you >> have it in JSF, CDI and finally surely all specs...same as >> converters... >> > ?That was originally the idea, when doing a EE config JSR, but without > such standard. I agree, CDI is not the place to define them. > > > >> Config should really be split in: >> 1) spec dependent config -> spec.xml >> 2) *common* config (a bit like javax.annotation) for environment and >> external configuration -> Config JSR >> > ?Not 100% sure, if a get the point here... > > > > > > 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : > >> well sorry to pop in so late but here are my 2cts >> >> Config JSR is more about environment config IMHO and putting it in CDI >> doesn't make sense since more or more spec works without any other >> spec - CDI in our case. This mean CDI can't be the place but should >> just be the bridge for config JSR. Plus CDI config will surely highly >> be an application config first (beans.xml should be the place then) >> then environment config can be done at EE level (saying it has to >> support placeholders or any pre deployment processing). >> >> If you put something like ProjectStage in CDI it is great but then you >> have it in JSF, CDI and finally surely all specs...same as >> converters... >> >> Config should really be split in: >> 1) spec dependent config -> spec.xml >> 2) *common* config (a bit like javax.annotation) for environment and >> external configuration -> Config JSR >> >> wdyt? >> >> >> >> Romain Manni-Bucau >> Twitter: @rmannibucau >> Blog: http://rmannibucau.wordpress.com/ >> LinkedIn: http://fr.linkedin.com/in/rmannibucau >> Github: https://github.com/rmannibucau >> >> >> 2014-09-07 23:39 GMT+02:00 Werner Keil : >> > Sounds like an argument for a CDI module rather than a separate JSR >> then?;-) >> > >> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch >> wrote: >> >> >> >> I would not worry about CDI regarding licensing. Just the sentence was >> >> that Oracle does not want to have more ALv2 in addition to what is >> already >> >> there. So as long as we do things within CDI, no worries, I think. For >> new >> >> EE JSRs nevertheless this is a BIG issue and should be clarified by >> the EC! >> >> >> >> >> >> 2014-09-07 21:44 GMT+02:00 Werner Keil : >> >>> >> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under >> ALv2 >> >>> as a dual-license, this was discussed by EC Members but both JCP EC >> and >> >>> Oracle Legal/PMO seems fine with it, and CDI is already an essential >> >>> building block to Java EE 6/7, hence used with Glassfish, too. I >> wasn't >> >>> involved in these discussions, but given CDI is especially liberal >> and fully >> >>> accepted by JCP formalities and license policies, I don't really see >> what >> >>> the problem wss for Anatole's JSR attempt (though I know, both Oracle >> and >> >>> other EC Members/companies don't always prefer this kind of >> licensing...;-) >> >>> >> >>> Werner >> >>> >> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament > > >> >>> wrote: >> >>>> >> >>>> Ok, this mail has me more concerned than anything. Can you clarify >> this >> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. >> >>>> >> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch >> >>>> wrote: >> >>>>> >> >>>>> Hi All >> >>>>> >> >>>>> unfortunately things seem quite complicated: >> >>>>> >> >>>>> first of all, similarities with Deltaspike are basically not >> >>>>> accidental. The concepts we developed in Credit Suisse are very >> similar to >> >>>>> Deltaspike, though Deltaspike was not yet born at that time. >> Fortunately we >> >>>>> ended up with a similar kind of solution. >> >>>>> filtering still can be done. My idea is to define some kind of >> >>>>> "configuration provider", which then is dynamically asked for >> configuration. >> >>>>> How the provider is internally organized, is completely transparent >> to CDI. >> >>>>> This enables to have multi-layered, complex config solutions work >> the same >> >>>>> (from a view point of CDI) like simple programmatic test >> configurations >> >>>>> during unit tests. The config provider still can support filtering >> and >> >>>>> dynamic resolution as commonly used in configuration systems. >> Similarly the >> >>>>> format is basically also not fixed. Of course, would a reference >> >>>>> implementation provide a set of functionalities, but I would >> definitively >> >>>>> not define the exact configuration mechanism as part of the CDI (or >> even a >> >>>>> EE config JSR). Another reason, beside complexity and time, is the >> fact that >> >>>>> different companies handle, store and manage configuration >> differently, so a >> >>>>> mechanism must be flexible enough to accommodate these, without >> adoption >> >>>>> rate will be low. Furthermore this flexibility also keeps doors >> open for use >> >>>>> cases we do not know yet. >> >>>>> Also we have to separate some basically two types of configuration >> >>>>> aspects: >> >>>>> >> >>>>> application config basically is injected into deployed components, >> but >> >>>>> basically only can affect deployment to the extend it can be >> managed and >> >>>>> injected by CDI. The basic architecture and design, how application >> servers >> >>>>> to load and deploy are basically not affected. This type of >> configuration >> >>>>> (mechanism) I see also as a possible addition to CDI, if we really >> fail to >> >>>>> do something in another JSR. With CDI going for a more modular >> design, even >> >>>>> basic configuration of CDI can be possible, given we have some kind >> of API, >> >>>>> we can access during CDI initialization. >> >>>>> On the other side deployment configuration affects directly how the >> >>>>> application server deploys the application. Configuration here >> would allow >> >>>>> to define datasources, EJBs, transactional aspects, security, >> persistence, >> >>>>> war and ear configurations etc. Basically everything you do as of >> today with >> >>>>> some kind of XML file, or annotation. Hereby enabling more >> flexibility into >> >>>>> the existing descriptors is relatively easy, but as mentioned by >> Mark, >> >>>>> constraint. Adding more flexibility raises other subtle problems. >> Imagine a >> >>>>> application module, e.g. a war, that defines everything it >> requires. There >> >>>>> is no need to configure anything more on server side (with spring >> you can do >> >>>>> this, with Java EE unfortunately not). But this has a severe >> consequence, it >> >>>>> would make the application really portable in the sense, that it >> can be >> >>>>> moved between different app servers (vendors) without any change >> (ideally). >> >>>>> As a result commercial profits of some vendor companies may be >> affected. I >> >>>>> think this is actually one of the key points, why things are >> getting so >> >>>>> complicated in that area. >> >>>>> >> >>>>> Legal aspects also were discussed. One of them is a possible legal >> >>>>> clash of ALv2 with GPL. This is the case already within Glassfish, >> but one >> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal >> department. At >> >>>>> the end we decided to use a BSD model. Even dual licensing BSD/ALv2 >> could >> >>>>> theoretically be an option. If you would choose ALv2, Oracle will >> not >> >>>>> include your RI into Glassfish, which is the RI for the EE Umbrella >> JSR, >> >>>>> meaning your JSR will not be included into EE8. So what should we >> do? I >> >>>>> don't have a good answer... >> >>>>> >> >>>>> So, I like to discuss configuration aspects here. Nevertheless if we >> >>>>> decide to add config aspects, be aware that we might only (mainly) >> support >> >>>>> application config, since everything else directly would impact >> other JSRs. >> >>>>> And that is obviously quite similar to what Apache Deltaspike is >> all about >> >>>>> ;-) >> >>>>> >> >>>>> Cheers, >> >>>>> Anatole >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : >> >>>>>> >> >>>>>> Yes, the config group also was (obviously) looking at DeltaSpikes >> >>>>>> config mechanism as well. >> >>>>>> There were others who wanted to go more into the 'filtering' >> approach >> >>>>>> as done on WebLogic servers (though not sure who else does that as >> well). >> >>>>>> You know, having all the XML configs like WEB-INF/web.xml >> containing >> >>>>>> placeholders and the real values only get placed in there at >> deployment >> >>>>>> time. I personally find this approach a bit limited from a >> technical >> >>>>>> perspective and it already didn't work out for me when using >> WebLogic (what >> >>>>>> about changing a configured value after the deployment was done? >> What about >> >>>>>> security? Having passwords in web.xml, unit testing, ...). >> >>>>>> There are of course also other approaches which all might have >> strong >> >>>>>> sides and would have needed to get discussed. >> >>>>>> >> >>>>>> But utterly the problem seems to have been legal reasons. We even >> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF >> project with >> >>>>>> substantial support and participation from the JBoss, DeltaSpike >> and TomEE >> >>>>>> communities. >> >>>>>> >> >>>>>> Anyway, the time will come when we will resurrect this effort. >> >>>>>> >> >>>>>> LieGrue, >> >>>>>> strub >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil >> >>>>>> wrote: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Yep, it contains a simple but extendable notion of ProjectStage, >> >>>>>> too;-) >> >>>>>> >> >>>>>> >> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament < >> john.d.ament at gmail.com> >> >>>>>> wrote: >> >>>>>> >> >>>>>> Anatole, >> >>>>>> >> >>>>>> I'm wondering if some of your configuration description falls under >> >>>>>> what was put together in DeltaSpike? >> >>>>>> >> >>>>>> http://deltaspike.apache.org/configuration.html >> >>>>>> >> >>>>>> John >> >>>>>> >> >>>>>> >> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch > > >> >>>>>> wrote: >> >>>>>> >> >>>>>> Staging is not a question of xml or not xml (the "format" of >> config). >> >>>>>> You can do staged config also using xml, or based on a database or >> json >> >>>>>> config service. Staging as well as, more generally speaking, >> environment >> >>>>>> dependent config is more like to select/filter the right config >> that targets >> >>>>>> the current (runtime) environment. This might include stages, but >> also many >> >>>>>> other aspects are feasible and common (server, tier, ear, war, >> tenant ...). >> >>>>>> Since these aspects are per se very complex, it might be advisable >> to leave >> >>>>>> them out of any spec (even a dedicated config JSR would probably >> not be >> >>>>>> capable of covering these within the relatively short EE >> timeframe)... >> >>>>>> >> >>>>>> >> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil : >> >>>>>> >> >>>>>> Jens/all, >> >>>>>> >> >>>>>> A sort of "staging" already was possible using CDI earlier, see >> >>>>>> examples like this: >> >>>>>> >> >>>>>> >> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >> >>>>>> >> >>>>>> DeltaSpike also includes type-safe staging that goes beyond the >> >>>>>> primitive, hard-coded JSF enum. >> >>>>>> >> >>>>>> If that works without XML, while still allowing flexible >> configuration >> >>>>>> for different stages or to add and "inject" additional stages >> maybe even on >> >>>>>> a tenant basis (for Cloud scenarios) I could see something like >> that work >> >>>>>> without XML. In the Multiconf project we managed to code >> everything in >> >>>>>> Python, and similar to Puppet or Chef you can configure and deploy >> multiple >> >>>>>> environments with it, Java EE, Spring or Play! several of them are >> >>>>>> configured this way and it requires no XML (where the container >> needs such >> >>>>>> files, the framework generates them;-) >> >>>>>> >> >>>>>> Werner >> >>>>>> >> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, >> >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole >> Tresch) >> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >> >>>>>> (Anatole Tresch (JIRA)) >> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) >> >>>>>> >> >>>>>> ------------------------------ >> >>>>>> >> >>>>>> Message: 4 >> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >> >>>>>> From: Jens Schumann >> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... >> >>>>>> To: Anatole Tresch , Antonio Goncalves >> >>>>>> >> >>>>>> Cc: cdi-dev >> >>>>>> Message-ID: >> >>>>>> Content-Type: text/plain; charset="windows-1252" >> >>>>>> >> >>>>>> I can confirm that this approach works very well. We are using a >> >>>>>> similar approach a couple of years now, and I love the simplicity >> that comes >> >>>>>> with portable extensions and @Producer methods. See our public >> version here >> >>>>>> [1] (works since early CDI 1.0 days) . >> >>>>>> >> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier >> @Property. >> >>>>>> We support default values and type conversation for primitives and >> >>>>>> everything that has a string based constructor. The property >> source can be >> >>>>>> anything, from property files (default) to databases or xml files. >> For >> >>>>>> examples see tests here [2]. >> >>>>>> >> >>>>>> Nevertheless I am not sure if this should be part of an future CDI >> >>>>>> spec. My concerns include the bloat argument, of course. But the >> main reason >> >>>>>> relates to the fact that we have almost everything in the current >> CDI spec >> >>>>>> already. >> >>>>>> >> >>>>>> Right now I am quite happy with an custom portable extension that >> does >> >>>>>> everything for me. At the time we implemented the extension we >> realised that >> >>>>>> the "hard part" was writing an extension that links a qualified >> "optional >> >>>>>> injection point" with an @Producer method while supporting code >> based >> >>>>>> default values. Luckily I had Arne in my team who did that within >> a few >> >>>>>> minutes. >> >>>>>> >> >>>>>> Because of this experience I would propose that we simplify >> extension >> >>>>>> development such that "optional injection points" may be linked to >> @Produces >> >>>>>> values easily. Additionally we have to solve a few more >> integration issues >> >>>>>> (e.g. read-only DB access should be available during CDI startup). >> >>>>>> Everything else should be provided by portable extensions (e.g. via >> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. >> >>>>>> >> >>>>>> Jens >> >>>>>> [1] >> >>>>>> >> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >> >>>>>> [2] >> >>>>>> >> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >> >>>>>> >> >>>>>> Von: Anatole Tresch > >> >> >>>>>> Datum: Friday 5 September 2014 21:22 >> >>>>>> An: Antonio Goncalves >> >>>>>> > >> >>>>>> Cc: CDI-Dev > cdi-dev at lists.jboss.org>> >> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... >> >>>>>> >> >>>>>> Hi all, >> >>>>>> >> >>>>>> I would not like to add an XML "bloated" mechanism as part of CDI >> 2.0. >> >>>>>> Spontaneously I would propose a more CDI like things like: >> >>>>>> >> >>>>>> >> >>>>>> * Adding a @Configured annotation (basically a qualifier). This >> >>>>>> can be in addition to @Inject and would allow to inject >> "configured" values. >> >>>>>> * Since configuration can change we may think of a (CDI) >> >>>>>> event/reinject mechanism based on config changes. By default, this >> is >> >>>>>> switched off and we can discuss how it would be activated, e.g. by >> an >> >>>>>> additional flag settable with the @Configured annotation, or an >> additional >> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon framework), >> or both. >> >>>>>> * Hereby configured values theoretically behave similar as all >> >>>>>> other injection points. They also can be qualified (the aspect of >> scopes, I >> >>>>>> did not yet have time to think about). The only difference is, >> that they are >> >>>>>> satisified using the configuration "system". >> >>>>>> * The configuration "source" itself could in the extreme >> simplest >> >>>>>> way be a Provider>. The CDI spec should not >> care about >> >>>>>> how this map is provided (XML, DB, overrides, etc). This still can >> be >> >>>>>> standardized later. As long as the ConfigurationSource SPI is >> defined, >> >>>>>> companies still can hook in the logic and level of configuration >> abstraction >> >>>>>> they need. >> >>>>>> * Of course, since not only Strings can be injected, we need >> some >> >>>>>> conversion or adapter logic as basically outlined in my blog. Also >> here we >> >>>>>> can add a simple SPI and let the details to the RI. >> >>>>>> >> >>>>>> Summarizing a >> >>>>>> >> >>>>>> * @Configured annotation >> >>>>>> * some kind of change event >> >>>>>> * a ConfigurationSource extends Provider> >> >>>>>> * a conversion mechanism from String to T. >> >>>>>> >> >>>>>> we get a full fledged configuration mechanism that leverages CDI. >> >>>>>> >> >>>>>> That would be my idea basically. WDYT? I will try to work that out >> in >> >>>>>> more details. Basically it should be implementable even with the >> CDI >> >>>>>> mechanism already in place with CDI 1.1. >> >>>>>> >> >>>>>> Best, >> >>>>>> Anatole >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >> >>>>>> >: >> >>>>>> One wise man* once said "EJB was a hype specification, we added too >> >>>>>> many things to it, it became bloated. The next hype specifications >> are >> >>>>>> JAX-RS and CDI, careful with them" >> >>>>>> >> >>>>>> Either we get this idea of "parts" right, or CDI will endup being >> >>>>>> bloated. >> >>>>>> >> >>>>>> Antonio >> >>>>>> >> >>>>>> >> >>>>>> *David Blevin >> >>>>>> >> >>>>>> >> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand >> >>>>>> > wrote: >> >>>>>> Hi all, >> >>>>>> >> >>>>>> You may have followed the rise and fall of the Java Config JSR >> >>>>>> ( >> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >> ). >> >>>>>> Anatole in CC was leading this initiative and I proposed him to >> join >> >>>>>> us and explore if some part of his late-JSR could be done in CDI. >> >>>>>> >> >>>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >> >>>>>> related solution. If we achieve to have a majority of specs to >> integrate >> >>>>>> with CDI, our configuration solution would therefore become a >> configuration >> >>>>>> system for all spec based on CDI 2.0. >> >>>>>> >> >>>>>> 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. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Antonio Goncalves >> >>>>>> Software architect, Java Champion and Pluralsight author >> >>>>>> >> >>>>>> Web site | >> >>>>>> Twitter | >> >>>>>> LinkedIn | >> >>>>>> Pluralsight< >> http://pluralsight.com/training/Authors/Details/antonio-goncalves> >> >>>>>> | Paris JUG | Devoxx France< >> http://www.devoxx.fr> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> 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. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Anatole Tresch >> >>>>>> Java Lead Engineer, JSR Spec Lead >> >>>>>> Gl?rnischweg 10 >> >>>>>> CH - 8620 Wetzikon >> >>>>>> >> >>>>>> Switzerland, Europe Zurich, GMT+1 >> >>>>>> Twitter: @atsticks >> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >> >>>>>> Google: atsticks >> >>>>>> Mobile +41-76 344 62 79 >> >>>>>> -------------- next part -------------- >> >>>>>> An HTML attachment was scrubbed... >> >>>>>> URL: >> >>>>>> >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >> >>>>>> *************************************** >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> 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. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Anatole Tresch >> >>>>>> Java Lead Engineer, JSR Spec Lead >> >>>>>> Gl?rnischweg 10 >> >>>>>> CH - 8620 Wetzikon >> >>>>>> >> >>>>>> Switzerland, Europe Zurich, GMT+1 >> >>>>>> Twitter: @atsticks >> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >> >>>>>> Google: atsticks >> >>>>>> Mobile +41-76 344 62 79 >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> 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. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> 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. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Anatole Tresch >> >>>>> Java Lead Engineer, JSR Spec Lead >> >>>>> Gl?rnischweg 10 >> >>>>> CH - 8620 Wetzikon >> >>>>> >> >>>>> Switzerland, Europe Zurich, GMT+1 >> >>>>> Twitter: @atsticks >> >>>>> Blogs: http://javaremarkables.blogspot.ch/ >> >>>>> Google: atsticks >> >>>>> Mobile +41-76 344 62 79 >> >>>> >> >>>> >> >>> >> >> >> >> >> >> >> >> -- >> >> Anatole Tresch >> >> Java Lead Engineer, JSR Spec Lead >> >> Gl?rnischweg 10 >> >> CH - 8620 Wetzikon >> >> >> >> Switzerland, Europe Zurich, GMT+1 >> >> Twitter: @atsticks >> >> Blogs: http://javaremarkables.blogspot.ch/ >> >> Google: atsticks >> >> Mobile +41-76 344 62 79 >> > >> > >> > >> > _______________________________________________ >> > 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. >> > > > > -- > *Anatole Tresch* > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > * > > *Google: atsticksMobile +41-76 344 62 79* > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/546cf87e/attachment-0001.html From issues at jboss.org Mon Sep 8 02:16:04 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 8 Sep 2014 02:16:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Add a disposable interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999697#comment-12999697 ] Mark Struberg commented on CDI-457: ----------------------------------- Please let me ask one question: why should the container know about dependent scoped beans which are _not_ injected into some normalscoped bean? We do not spare any resources for them (at least in OWB). Even if they have interceptors or decorators applied. Btw, there is kind off such a mechanism already. All you need to do is to keep the Bean and the CreationalContext you used to create the contextual instance. Then just use Bean.destroy(T, cc); > Add a disposable interface > -------------------------- > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed. > I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 03:27:02 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Mon, 8 Sep 2014 03:27:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999716#comment-12999716 ] Jozef Hartinger commented on CDI-456: ------------------------------------- Anatole, you are completely right. But why does it work this way? The behavior is driven by the following statement in the specification: {quote}A bean is available for injection in a certain module if the *bean class* is required to be *accessible to classes in the module*, according to the class accessibility requirements of the module architecture.{quote} Let's expand your example a bit to demonstrate this. Let's say that your producers are called {{MyProducer1}}, {{MyProducer2}}, {{MyProducer3}} and are packaged in war1, war2 and war3, respectively. Now, let's inject {{MyBean}} in war1. {{MyProducer1.create()}} is the first candidate. Since the bean class of {{MyProducer1.create()}} is {{MyProducer1}} and since this class is accessible within war1, we can use {{MyProducer1.create()}} to create a {{MyBean}} instance. For {{MyProducer2}} and {{MyProducer3}} this is not the case as we assume wars are isolated. This is expected and in line with your conclusion. Notice that although {{MyProducer1.create()}} produces {{MyBean}} instances, {{MyProducer1}} is its bean class. If we made {{MyBean}} the bean class of {{MyProducer1}}, {{MyProducer2}} and {{MyProducer3}} (*as this ticket proposes*), all three producer methods would be available for injection in any of the wars, which is obviously not desired! The aforementioned CDI accessibility rule determines the accessibility of the bean by its bean class and therefore we cannot pronounce the return type of a producer method as its bean class. \\ ---- \\ Custom Bean implementations are very similar. Image now that instead of using {{MyProducer}} classes, our example uses {{MyBeanProvider}} classes defined as: {code:JAVA} public class MyBeanProvider implements Bean { public T create(CreationalContext creationalContext) { return new MyBean(); } ... } {code} Again, we have {{MyBeanProvider1}}, {{MyBeanProvider2}}, {{MyBeanProvider3}} in war1, war2, war3, respectively. Each bean provider is registered by an extension. What should {{MyBeanProvider1.getBeanClass()}} return? Let's assume it returns {{MyBeanProvider1.class}}. Once we apply the accessibility rule of CDI we can see that each war again gets its respective bean producing MyBean instances and that the bean isolation follows classloader isolation. This is again the expected behavior, matching Anatole's example. If we however follow the "simplification proposed by this ticket" and return {{MyBean.class}} from {{MyBeanProvider1.getBeanClass()}} then, not unlike with producers, {{MyBeanProvider1}} will be visible from all the three wars, which is not desired. This would be because {{MyBean.class}} is accessible from all the three wars. The CDI accessibility rule determines the accessibility of the bean by its bean class and therefore we cannot just blindly return a bean type from {{Bean.getBeanClass()}}. Hope this makes it clearer that {{Bean.getBeanClass()}} * exists for a reason * it is not a shortcut to bean types and there is often absolutely no relation between Bean.getTypes() and Bean.getBeanClass() * although probably not the ideal way of addressing modularity and isolation (and subject to improvement in CDI 2.0), it works * cannot be redefined to simply return the bean type - besides breaking backward compatibility this would also break how other parts of CDI work > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 03:30:01 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 8 Sep 2014 03:30:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999720#comment-12999720 ] Romain Manni-Bucau commented on CDI-456: ---------------------------------------- Not sure I get {quote} * cannot be redefined to simply return the bean type - besides breaking backward compatibility this would also break how other parts of CDI work {quote} Enough to define it well next tim, no? > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 03:31:06 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 8 Sep 2014 03:31:06 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999722#comment-12999722 ] Martin Kouba commented on CDI-4: -------------------------------- [~agoncal] Hm, so it woudn't work for Java 8 SE without some dependency tuning, right? I'm just pointing out there is a little complication... > Need a way to provide ordering for Event observers > -------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: 2.0 (discussion) > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 03:39:00 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Mon, 8 Sep 2014 03:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999727#comment-12999727 ] Jozef Hartinger commented on CDI-456: ------------------------------------- {quote}Enough to define it well next tim, no?{quote} We cannot just redefine the method's behavior (as otherwise we break other things). We can: 1) define a new better mechanism for this, or 2) redefine the method behavior and the related parts of the spec while retaining backward compatibility (hard or perhaps not possible at all), or 3) leave it as it is > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antonio.goncalves at gmail.com Mon Sep 8 03:47:14 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 8 Sep 2014 09:47:14 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Hi all, I really have some concerns about adding configuration into CDI but I can see benefits too. And what about adding it... and not adding it at the same time ? In Bean Validation 1.0, the Expert Group decided not to include method-level validation in the spec (it was included in 1.1). But what they did is to add it as a proposal in the Appendix. If we feel some configuration should get in, why not have a proposal in the Appendix of CDI 2.0 ? It could then be implemented by Weld (and OpenWebBeans if they feel like it). And then, if it's successful and things get easier, get its own JSR for Java EE 9. WDYT ? Antonio On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau wrote: > Hmm > > I see config jsr as a jse spec which would allow EE injections in config > components in EE containers (exactly like jbatch). > > This way it can be used without any container or with any container > easily. Only limit will be to not do something cdi/known containers will > not support I think. > > Not sure EE side is needed today, a lot can already be done without it and > it can be enhanced later adding some integration words. > Le 8 sept. 2014 00:01, "Anatole Tresch" a ?crit : > > Hi Romain >> >> just a few remarks inline... >> >> Summarizing >> 1) injection of values, reinjection, feedback on config changes can all >> be done with already existing features (producers, extensions). >> 2) configuring/bootstrapping CDI itself, e.g. configuration, is targeted >> with CDI 2.0 (see spec failing) >> >> So basically we could try to look if there is enough interest to >> standardize configuration in a more general way. For deployment aspects we >> need an EE JSR, for the rest, another SE standard may be an option as >> well... tbd... >> >> -Anatole >> >> >> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : >> >>> well sorry to pop in so late but here are my 2cts >>> >> ?easy ;)? >> >> >>> Config JSR is more about environment config IMHO and putting it in CDI >>> doesn't make sense since more or more spec works without any other >>> spec - CDI in our case. >> >> ?CDI even with some config mechanism added would still work "standalone".? >> >> >> >>> This mean CDI can't be the place but should >>> just be the bridge for config JSR. >> >> ?As I suggested as well.? >> >> >> >>> Plus CDI config will surely highly >>> be an application config first (beans.xml should be the place then) >>> >> ?Yes, app config, but beware people of writing config into beans.xml. >> That is definitively in most cases not what you want.? CDI should not >> define, where and how config is located and formatted. CDI should provide a >> SPI, where config providers can publish the configured values, so it can be >> injected wherever needed. E.g. some kind of producer, that can provide >> multiple objects to be injected and can benefit from some kind of callback >> mechanism would be sufficient... >> >> >>> then environment config can be done at EE level (saying it has to >>> support placeholders or any pre deployment processing). >>> >> ?Config is much more complex. There is no clear border what is >> environment config or environment dependent and what not. This depends on >> what kind of application you have deployed. As an example the email >> address, where you send error messages, can be different depenending on the >> stage/environment, but this is not EE related config entry. Also what an >> environment is, is not a thing that you can define completely. So I agree >> not to add this complexities to CDI, I would hide them between some kind of >> "config provider", as mentioned above.? CDI does not need to know if the >> config provided is environment dependent or not, its just what is visible >> at a current runtime state... >> >> >>> If you put something like ProjectStage in CDI it is great but then you >>> have it in JSF, CDI and finally surely all specs...same as >>> converters... >>> >> ?That was originally the idea, when doing a EE config JSR, but without >> such standard. I agree, CDI is not the place to define them. >> >> >> >>> Config should really be split in: >>> 1) spec dependent config -> spec.xml >>> 2) *common* config (a bit like javax.annotation) for environment and >>> external configuration -> Config JSR >>> >> ?Not 100% sure, if a get the point here... >> >> >> >> >> >> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : >> >>> well sorry to pop in so late but here are my 2cts >>> >>> Config JSR is more about environment config IMHO and putting it in CDI >>> doesn't make sense since more or more spec works without any other >>> spec - CDI in our case. This mean CDI can't be the place but should >>> just be the bridge for config JSR. Plus CDI config will surely highly >>> be an application config first (beans.xml should be the place then) >>> then environment config can be done at EE level (saying it has to >>> support placeholders or any pre deployment processing). >>> >>> If you put something like ProjectStage in CDI it is great but then you >>> have it in JSF, CDI and finally surely all specs...same as >>> converters... >>> >>> Config should really be split in: >>> 1) spec dependent config -> spec.xml >>> 2) *common* config (a bit like javax.annotation) for environment and >>> external configuration -> Config JSR >>> >>> wdyt? >>> >>> >>> >>> Romain Manni-Bucau >>> Twitter: @rmannibucau >>> Blog: http://rmannibucau.wordpress.com/ >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>> Github: https://github.com/rmannibucau >>> >>> >>> 2014-09-07 23:39 GMT+02:00 Werner Keil : >>> > Sounds like an argument for a CDI module rather than a separate JSR >>> then?;-) >>> > >>> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch >>> wrote: >>> >> >>> >> I would not worry about CDI regarding licensing. Just the sentence was >>> >> that Oracle does not want to have more ALv2 in addition to what is >>> already >>> >> there. So as long as we do things within CDI, no worries, I think. >>> For new >>> >> EE JSRs nevertheless this is a BIG issue and should be clarified by >>> the EC! >>> >> >>> >> >>> >> 2014-09-07 21:44 GMT+02:00 Werner Keil : >>> >>> >>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under >>> ALv2 >>> >>> as a dual-license, this was discussed by EC Members but both JCP EC >>> and >>> >>> Oracle Legal/PMO seems fine with it, and CDI is already an essential >>> >>> building block to Java EE 6/7, hence used with Glassfish, too. I >>> wasn't >>> >>> involved in these discussions, but given CDI is especially liberal >>> and fully >>> >>> accepted by JCP formalities and license policies, I don't really see >>> what >>> >>> the problem wss for Anatole's JSR attempt (though I know, both >>> Oracle and >>> >>> other EC Members/companies don't always prefer this kind of >>> licensing...;-) >>> >>> >>> >>> Werner >>> >>> >>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament < >>> john.d.ament at gmail.com> >>> >>> wrote: >>> >>>> >>> >>>> Ok, this mail has me more concerned than anything. Can you clarify >>> this >>> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. >>> >>>> >>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch >>> >>>> wrote: >>> >>>>> >>> >>>>> Hi All >>> >>>>> >>> >>>>> unfortunately things seem quite complicated: >>> >>>>> >>> >>>>> first of all, similarities with Deltaspike are basically not >>> >>>>> accidental. The concepts we developed in Credit Suisse are very >>> similar to >>> >>>>> Deltaspike, though Deltaspike was not yet born at that time. >>> Fortunately we >>> >>>>> ended up with a similar kind of solution. >>> >>>>> filtering still can be done. My idea is to define some kind of >>> >>>>> "configuration provider", which then is dynamically asked for >>> configuration. >>> >>>>> How the provider is internally organized, is completely >>> transparent to CDI. >>> >>>>> This enables to have multi-layered, complex config solutions work >>> the same >>> >>>>> (from a view point of CDI) like simple programmatic test >>> configurations >>> >>>>> during unit tests. The config provider still can support filtering >>> and >>> >>>>> dynamic resolution as commonly used in configuration systems. >>> Similarly the >>> >>>>> format is basically also not fixed. Of course, would a reference >>> >>>>> implementation provide a set of functionalities, but I would >>> definitively >>> >>>>> not define the exact configuration mechanism as part of the CDI >>> (or even a >>> >>>>> EE config JSR). Another reason, beside complexity and time, is the >>> fact that >>> >>>>> different companies handle, store and manage configuration >>> differently, so a >>> >>>>> mechanism must be flexible enough to accommodate these, without >>> adoption >>> >>>>> rate will be low. Furthermore this flexibility also keeps doors >>> open for use >>> >>>>> cases we do not know yet. >>> >>>>> Also we have to separate some basically two types of configuration >>> >>>>> aspects: >>> >>>>> >>> >>>>> application config basically is injected into deployed components, >>> but >>> >>>>> basically only can affect deployment to the extend it can be >>> managed and >>> >>>>> injected by CDI. The basic architecture and design, how >>> application servers >>> >>>>> to load and deploy are basically not affected. This type of >>> configuration >>> >>>>> (mechanism) I see also as a possible addition to CDI, if we really >>> fail to >>> >>>>> do something in another JSR. With CDI going for a more modular >>> design, even >>> >>>>> basic configuration of CDI can be possible, given we have some >>> kind of API, >>> >>>>> we can access during CDI initialization. >>> >>>>> On the other side deployment configuration affects directly how the >>> >>>>> application server deploys the application. Configuration here >>> would allow >>> >>>>> to define datasources, EJBs, transactional aspects, security, >>> persistence, >>> >>>>> war and ear configurations etc. Basically everything you do as of >>> today with >>> >>>>> some kind of XML file, or annotation. Hereby enabling more >>> flexibility into >>> >>>>> the existing descriptors is relatively easy, but as mentioned by >>> Mark, >>> >>>>> constraint. Adding more flexibility raises other subtle problems. >>> Imagine a >>> >>>>> application module, e.g. a war, that defines everything it >>> requires. There >>> >>>>> is no need to configure anything more on server side (with spring >>> you can do >>> >>>>> this, with Java EE unfortunately not). But this has a severe >>> consequence, it >>> >>>>> would make the application really portable in the sense, that it >>> can be >>> >>>>> moved between different app servers (vendors) without any change >>> (ideally). >>> >>>>> As a result commercial profits of some vendor companies may be >>> affected. I >>> >>>>> think this is actually one of the key points, why things are >>> getting so >>> >>>>> complicated in that area. >>> >>>>> >>> >>>>> Legal aspects also were discussed. One of them is a possible legal >>> >>>>> clash of ALv2 with GPL. This is the case already within Glassfish, >>> but one >>> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal >>> department. At >>> >>>>> the end we decided to use a BSD model. Even dual licensing >>> BSD/ALv2 could >>> >>>>> theoretically be an option. If you would choose ALv2, Oracle will >>> not >>> >>>>> include your RI into Glassfish, which is the RI for the EE >>> Umbrella JSR, >>> >>>>> meaning your JSR will not be included into EE8. So what should we >>> do? I >>> >>>>> don't have a good answer... >>> >>>>> >>> >>>>> So, I like to discuss configuration aspects here. Nevertheless if >>> we >>> >>>>> decide to add config aspects, be aware that we might only (mainly) >>> support >>> >>>>> application config, since everything else directly would impact >>> other JSRs. >>> >>>>> And that is obviously quite similar to what Apache Deltaspike is >>> all about >>> >>>>> ;-) >>> >>>>> >>> >>>>> Cheers, >>> >>>>> Anatole >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : >>> >>>>>> >>> >>>>>> Yes, the config group also was (obviously) looking at DeltaSpikes >>> >>>>>> config mechanism as well. >>> >>>>>> There were others who wanted to go more into the 'filtering' >>> approach >>> >>>>>> as done on WebLogic servers (though not sure who else does that >>> as well). >>> >>>>>> You know, having all the XML configs like WEB-INF/web.xml >>> containing >>> >>>>>> placeholders and the real values only get placed in there at >>> deployment >>> >>>>>> time. I personally find this approach a bit limited from a >>> technical >>> >>>>>> perspective and it already didn't work out for me when using >>> WebLogic (what >>> >>>>>> about changing a configured value after the deployment was done? >>> What about >>> >>>>>> security? Having passwords in web.xml, unit testing, ...). >>> >>>>>> There are of course also other approaches which all might have >>> strong >>> >>>>>> sides and would have needed to get discussed. >>> >>>>>> >>> >>>>>> But utterly the problem seems to have been legal reasons. We even >>> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF >>> project with >>> >>>>>> substantial support and participation from the JBoss, DeltaSpike >>> and TomEE >>> >>>>>> communities. >>> >>>>>> >>> >>>>>> Anyway, the time will come when we will resurrect this effort. >>> >>>>>> >>> >>>>>> LieGrue, >>> >>>>>> strub >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil >>> >>>>>> wrote: >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> Yep, it contains a simple but extendable notion of ProjectStage, >>> >>>>>> too;-) >>> >>>>>> >>> >>>>>> >>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament < >>> john.d.ament at gmail.com> >>> >>>>>> wrote: >>> >>>>>> >>> >>>>>> Anatole, >>> >>>>>> >>> >>>>>> I'm wondering if some of your configuration description falls >>> under >>> >>>>>> what was put together in DeltaSpike? >>> >>>>>> >>> >>>>>> http://deltaspike.apache.org/configuration.html >>> >>>>>> >>> >>>>>> John >>> >>>>>> >>> >>>>>> >>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch < >>> atsticks at gmail.com> >>> >>>>>> wrote: >>> >>>>>> >>> >>>>>> Staging is not a question of xml or not xml (the "format" of >>> config). >>> >>>>>> You can do staged config also using xml, or based on a database >>> or json >>> >>>>>> config service. Staging as well as, more generally speaking, >>> environment >>> >>>>>> dependent config is more like to select/filter the right config >>> that targets >>> >>>>>> the current (runtime) environment. This might include stages, but >>> also many >>> >>>>>> other aspects are feasible and common (server, tier, ear, war, >>> tenant ...). >>> >>>>>> Since these aspects are per se very complex, it might be >>> advisable to leave >>> >>>>>> them out of any spec (even a dedicated config JSR would probably >>> not be >>> >>>>>> capable of covering these within the relatively short EE >>> timeframe)... >>> >>>>>> >>> >>>>>> >>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil : >>> >>>>>> >>> >>>>>> Jens/all, >>> >>>>>> >>> >>>>>> A sort of "staging" already was possible using CDI earlier, see >>> >>>>>> examples like this: >>> >>>>>> >>> >>>>>> >>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >>> >>>>>> >>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond the >>> >>>>>> primitive, hard-coded JSF enum. >>> >>>>>> >>> >>>>>> If that works without XML, while still allowing flexible >>> configuration >>> >>>>>> for different stages or to add and "inject" additional stages >>> maybe even on >>> >>>>>> a tenant basis (for Cloud scenarios) I could see something like >>> that work >>> >>>>>> without XML. In the Multiconf project we managed to code >>> everything in >>> >>>>>> Python, and similar to Puppet or Chef you can configure and >>> deploy multiple >>> >>>>>> environments with it, Java EE, Spring or Play! several of them are >>> >>>>>> configured this way and it requires no XML (where the container >>> needs such >>> >>>>>> files, the framework generates them;-) >>> >>>>>> >>> >>>>>> Werner >>> >>>>>> >>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, >> > >>> >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole >>> Tresch) >>> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >>> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>> >>>>>> (Anatole Tresch (JIRA)) >>> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) >>> >>>>>> >>> >>>>>> ------------------------------ >>> >>>>>> >>> >>>>>> Message: 4 >>> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >>> >>>>>> From: Jens Schumann >>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... >>> >>>>>> To: Anatole Tresch , Antonio Goncalves >>> >>>>>> >>> >>>>>> Cc: cdi-dev >>> >>>>>> Message-ID: >>> >>>>>> Content-Type: text/plain; charset="windows-1252" >>> >>>>>> >>> >>>>>> I can confirm that this approach works very well. We are using a >>> >>>>>> similar approach a couple of years now, and I love the simplicity >>> that comes >>> >>>>>> with portable extensions and @Producer methods. See our public >>> version here >>> >>>>>> [1] (works since early CDI 1.0 days) . >>> >>>>>> >>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier >>> @Property. >>> >>>>>> We support default values and type conversation for primitives and >>> >>>>>> everything that has a string based constructor. The property >>> source can be >>> >>>>>> anything, from property files (default) to databases or xml >>> files. For >>> >>>>>> examples see tests here [2]. >>> >>>>>> >>> >>>>>> Nevertheless I am not sure if this should be part of an future CDI >>> >>>>>> spec. My concerns include the bloat argument, of course. But the >>> main reason >>> >>>>>> relates to the fact that we have almost everything in the current >>> CDI spec >>> >>>>>> already. >>> >>>>>> >>> >>>>>> Right now I am quite happy with an custom portable extension that >>> does >>> >>>>>> everything for me. At the time we implemented the extension we >>> realised that >>> >>>>>> the "hard part" was writing an extension that links a qualified >>> "optional >>> >>>>>> injection point" with an @Producer method while supporting code >>> based >>> >>>>>> default values. Luckily I had Arne in my team who did that within >>> a few >>> >>>>>> minutes. >>> >>>>>> >>> >>>>>> Because of this experience I would propose that we simplify >>> extension >>> >>>>>> development such that "optional injection points" may be linked >>> to @Produces >>> >>>>>> values easily. Additionally we have to solve a few more >>> integration issues >>> >>>>>> (e.g. read-only DB access should be available during CDI startup). >>> >>>>>> Everything else should be provided by portable extensions (e.g. >>> via >>> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. >>> >>>>>> >>> >>>>>> Jens >>> >>>>>> [1] >>> >>>>>> >>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>> >>>>>> [2] >>> >>>>>> >>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>> >>>>>> >>> >>>>>> Von: Anatole Tresch >> >> >>> >>>>>> Datum: Friday 5 September 2014 21:22 >>> >>>>>> An: Antonio Goncalves >>> >>>>>> > >>> >>>>>> Cc: CDI-Dev >> cdi-dev at lists.jboss.org>> >>> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... >>> >>>>>> >>> >>>>>> Hi all, >>> >>>>>> >>> >>>>>> I would not like to add an XML "bloated" mechanism as part of CDI >>> 2.0. >>> >>>>>> Spontaneously I would propose a more CDI like things like: >>> >>>>>> >>> >>>>>> >>> >>>>>> * Adding a @Configured annotation (basically a qualifier). >>> This >>> >>>>>> can be in addition to @Inject and would allow to inject >>> "configured" values. >>> >>>>>> * Since configuration can change we may think of a (CDI) >>> >>>>>> event/reinject mechanism based on config changes. By default, >>> this is >>> >>>>>> switched off and we can discuss how it would be activated, e.g. >>> by an >>> >>>>>> additional flag settable with the @Configured annotation, or an >>> additional >>> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon framework), >>> or both. >>> >>>>>> * Hereby configured values theoretically behave similar as all >>> >>>>>> other injection points. They also can be qualified (the aspect of >>> scopes, I >>> >>>>>> did not yet have time to think about). The only difference is, >>> that they are >>> >>>>>> satisified using the configuration "system". >>> >>>>>> * The configuration "source" itself could in the extreme >>> simplest >>> >>>>>> way be a Provider>. The CDI spec should not >>> care about >>> >>>>>> how this map is provided (XML, DB, overrides, etc). This still >>> can be >>> >>>>>> standardized later. As long as the ConfigurationSource SPI is >>> defined, >>> >>>>>> companies still can hook in the logic and level of configuration >>> abstraction >>> >>>>>> they need. >>> >>>>>> * Of course, since not only Strings can be injected, we need >>> some >>> >>>>>> conversion or adapter logic as basically outlined in my blog. >>> Also here we >>> >>>>>> can add a simple SPI and let the details to the RI. >>> >>>>>> >>> >>>>>> Summarizing a >>> >>>>>> >>> >>>>>> * @Configured annotation >>> >>>>>> * some kind of change event >>> >>>>>> * a ConfigurationSource extends Provider> >>> >>>>>> * a conversion mechanism from String to T. >>> >>>>>> >>> >>>>>> we get a full fledged configuration mechanism that leverages CDI. >>> >>>>>> >>> >>>>>> That would be my idea basically. WDYT? I will try to work that >>> out in >>> >>>>>> more details. Basically it should be implementable even with the >>> CDI >>> >>>>>> mechanism already in place with CDI 1.1. >>> >>>>>> >>> >>>>>> Best, >>> >>>>>> Anatole >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >>> >>>>>> >> >>: >>> >>>>>> One wise man* once said "EJB was a hype specification, we added >>> too >>> >>>>>> many things to it, it became bloated. The next hype >>> specifications are >>> >>>>>> JAX-RS and CDI, careful with them" >>> >>>>>> >>> >>>>>> Either we get this idea of "parts" right, or CDI will endup being >>> >>>>>> bloated. >>> >>>>>> >>> >>>>>> Antonio >>> >>>>>> >>> >>>>>> >>> >>>>>> *David Blevin >>> >>>>>> >>> >>>>>> >>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand >>> >>>>>> > >>> wrote: >>> >>>>>> Hi all, >>> >>>>>> >>> >>>>>> You may have followed the rise and fall of the Java Config JSR >>> >>>>>> ( >>> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >>> ). >>> >>>>>> Anatole in CC was leading this initiative and I proposed him to >>> join >>> >>>>>> us and explore if some part of his late-JSR could be done in CDI. >>> >>>>>> >>> >>>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 or >>> >>>>>> related solution. If we achieve to have a majority of specs to >>> integrate >>> >>>>>> with CDI, our configuration solution would therefore become a >>> configuration >>> >>>>>> system for all spec based on CDI 2.0. >>> >>>>>> >>> >>>>>> 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. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> -- >>> >>>>>> Antonio Goncalves >>> >>>>>> Software architect, Java Champion and Pluralsight author >>> >>>>>> >>> >>>>>> Web site | >>> >>>>>> Twitter | >>> >>>>>> LinkedIn | >>> >>>>>> Pluralsight< >>> http://pluralsight.com/training/Authors/Details/antonio-goncalves> >>> >>>>>> | Paris JUG | Devoxx France< >>> http://www.devoxx.fr> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> 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. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> -- >>> >>>>>> Anatole Tresch >>> >>>>>> Java Lead Engineer, JSR Spec Lead >>> >>>>>> Gl?rnischweg 10 >>> >>>>>> CH - 8620 Wetzikon >>> >>>>>> >>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>> >>>>>> Twitter: @atsticks >>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>> >>>>>> Google: atsticks >>> >>>>>> Mobile +41-76 344 62 79 >>> >>>>>> -------------- next part -------------- >>> >>>>>> An HTML attachment was scrubbed... >>> >>>>>> URL: >>> >>>>>> >>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>> >>>>>> *************************************** >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> 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. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> -- >>> >>>>>> Anatole Tresch >>> >>>>>> Java Lead Engineer, JSR Spec Lead >>> >>>>>> Gl?rnischweg 10 >>> >>>>>> CH - 8620 Wetzikon >>> >>>>>> >>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>> >>>>>> Twitter: @atsticks >>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>> >>>>>> Google: atsticks >>> >>>>>> Mobile +41-76 344 62 79 >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> 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. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> 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. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> Anatole Tresch >>> >>>>> Java Lead Engineer, JSR Spec Lead >>> >>>>> Gl?rnischweg 10 >>> >>>>> CH - 8620 Wetzikon >>> >>>>> >>> >>>>> Switzerland, Europe Zurich, GMT+1 >>> >>>>> Twitter: @atsticks >>> >>>>> Blogs: http://javaremarkables.blogspot.ch/ >>> >>>>> Google: atsticks >>> >>>>> Mobile +41-76 344 62 79 >>> >>>> >>> >>>> >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Anatole Tresch >>> >> Java Lead Engineer, JSR Spec Lead >>> >> Gl?rnischweg 10 >>> >> CH - 8620 Wetzikon >>> >> >>> >> Switzerland, Europe Zurich, GMT+1 >>> >> Twitter: @atsticks >>> >> Blogs: http://javaremarkables.blogspot.ch/ >>> >> Google: atsticks >>> >> Mobile +41-76 344 62 79 >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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. >>> >> >> >> >> -- >> *Anatole Tresch* >> Java Lead Engineer, JSR Spec Lead >> Gl?rnischweg 10 >> CH - 8620 Wetzikon >> >> *Switzerland, Europe Zurich, GMT+1* >> *Twitter: @atsticks* >> *Blogs: **http://javaremarkables.blogspot.ch/ >> * >> >> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* >> > > _______________________________________________ > 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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/09333c54/attachment-0001.html From issues at jboss.org Mon Sep 8 03:51:01 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 8 Sep 2014 03:51:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999733#comment-12999733 ] Mark Struberg commented on CDI-456: ----------------------------------- to also add what we discussed on IRC on friday: Bean#getBeanClass() is _only_ defined for 'Managed Beans' at the moment. That means it is only defined for classes which get scanned at boot time. It is *not* defined for anything you do via Extensions. regarding the modularity discussion: yes, using getBeanClass() for that would work for ManagedBeans which get scanned by the container, but again: it wont work for 3 custom Bean which are differently configured for each of the 3 WARs. Especially since getBeanClass() might return null if you strictly follow the spec wording. So I think we need to a.) clarify what getBeanClass() shall return for Bean added via Extensions b.) how modularity works for synthetic beans. The whole modularity in EAR otoh requires that JavaEE FINALLY properly defines the default isolation (EAR as 1 classloader + each WAR as child ClassLoader, etc) as standard. If the EE platform doesn't have a proper modularity specification we have a floating target and cannot define how CDI should handle it neither. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 04:03:05 2014 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Mon, 8 Sep 2014 04:03:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999738#comment-12999738 ] Antonio Goncalves commented on CDI-4: ------------------------------------- Yes, that reminds me of {{javax.annotation.Resource}}. It got updated in Java EE 6 (it introduced the {{lookup()}} method) and we had to endorse the library for Java SE 6. So yes, there is a bit of tuning when you touch common code like [Commons Annotation|https://jcp.org/en/jsr/detail?id=250]. > Need a way to provide ordering for Event observers > -------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: 2.0 (discussion) > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 04:07:00 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Mon, 8 Sep 2014 04:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999739#comment-12999739 ] Jozef Hartinger commented on CDI-456: ------------------------------------- {quote}Bean#getBeanClass() is only defined for 'Managed Beans' at the moment. That means it is only defined for classes which get scanned at boot time. It is not defined for anything you do via Extensions.{quote} The Javadoc defines {{Bean#getBeanClass()}} for *managed beans, session beans, producer methods and producer fields*. Not just managed beans. In addition, although {{Bean#getBeanClass()}} is not explicitly defined for custom beans, the expected behavior can be implied from sections 5.1, 5.1.1.2 and 5.1.4. The behavior for custom beans should be defined more explicitly as currently it needs to be implied and is not immediately obvious. {quote} it wont work for 3 custom Bean which are differently configured for each of the 3 WARs{quote} See my example above. It works there. {quote}Especially since getBeanClass() might return null if you strictly follow the spec wording.{quote} {quote}For a custom implementation of the Bean interface defined in Section 11.1, ?The Bean interface?, the container calls getBeanClass() to determine the bean class of the bean{quote} Since 'bean class' is used in 5.1.4. to determine if the bean is available for injection then returning null from {{getBeanClass}} is arguably a definition error. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 04:13:02 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Mon, 8 Sep 2014 04:13:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999745#comment-12999745 ] Jozef Hartinger commented on CDI-456: ------------------------------------- {quote}The whole modularity in EAR otoh requires that JavaEE FINALLY properly defines the default isolation (EAR as 1 classloader + each WAR as child ClassLoader, etc) as standard. If the EE platform doesn't have a proper modularity specification we have a floating target and cannot define how CDI should handle it neither.{quote} Let's suppose for a moment that Java EE finally properly defined its module architecture. Now, how should we define CDI modularity? Should it follow the underlying module architecture or go against it? I think we can agree that we should not define a different architecture but rather follow the underlying one. But wait... that's what CDI already does by using class accessibility to infer bean accessibility ;-) > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From werner.keil at gmail.com Mon Sep 8 04:29:47 2014 From: werner.keil at gmail.com (Werner Keil) Date: Mon, 8 Sep 2014 10:29:47 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Hi, If it's not really usable as API or annotation I don't see much value in adding some "how to" or intent for the future into the Spec Document. If it was to become a part of CDI 2, there's nothing against optionality like MEEP 8 or JSR 363 already practice on the SE/EE side either. Agorava/DeltaSpike demonstrate how true modularity work, similar to the JSRs mentioned above, where you have multiple module JARs/bundles instead of a big monolithic one. Some JSRs like Batch also declared separate "annotation" modules, so that's what CDI 2 should also do if it was a feature Inside of it. Calling some features optional if they're not used by every implementation allows them to chose. That was also the main value of keeping @Inject a separate "module" under CDI. It was never included into a JDK but used independently. The core of a Config module would ideally work in SE, but CDI 2 already declared an aim to have some modules work under SE. Werner Am 08.09.2014 09:47 schrieb "Antonio Goncalves" : > Hi all, > > I really have some concerns about adding configuration into CDI but I can > see benefits too. And what about adding it... and not adding it at the same > time ? In Bean Validation 1.0, the Expert Group decided not to include > method-level validation in the spec (it was included in 1.1). But what they > did is to add it as a proposal in the Appendix. > > If we feel some configuration should get in, why not have a proposal in > the Appendix of CDI 2.0 ? It could then be implemented by Weld (and > OpenWebBeans if they feel like it). And then, if it's successful and things > get easier, get its own JSR for Java EE 9. > > WDYT ? > > Antonio > > On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau > wrote: > >> Hmm >> >> I see config jsr as a jse spec which would allow EE injections in config >> components in EE containers (exactly like jbatch). >> >> This way it can be used without any container or with any container >> easily. Only limit will be to not do something cdi/known containers will >> not support I think. >> >> Not sure EE side is needed today, a lot can already be done without it >> and it can be enhanced later adding some integration words. >> Le 8 sept. 2014 00:01, "Anatole Tresch" a ?crit : >> >> Hi Romain >>> >>> just a few remarks inline... >>> >>> Summarizing >>> 1) injection of values, reinjection, feedback on config changes can all >>> be done with already existing features (producers, extensions). >>> 2) configuring/bootstrapping CDI itself, e.g. configuration, is targeted >>> with CDI 2.0 (see spec failing) >>> >>> So basically we could try to look if there is enough interest to >>> standardize configuration in a more general way. For deployment aspects we >>> need an EE JSR, for the rest, another SE standard may be an option as >>> well... tbd... >>> >>> -Anatole >>> >>> >>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : >>> >>>> well sorry to pop in so late but here are my 2cts >>>> >>> ?easy ;)? >>> >>> >>>> Config JSR is more about environment config IMHO and putting it in CDI >>>> doesn't make sense since more or more spec works without any other >>>> spec - CDI in our case. >>> >>> ?CDI even with some config mechanism added would still work >>> "standalone".? >>> >>> >>> >>>> This mean CDI can't be the place but should >>>> just be the bridge for config JSR. >>> >>> ?As I suggested as well.? >>> >>> >>> >>>> Plus CDI config will surely highly >>>> be an application config first (beans.xml should be the place then) >>>> >>> ?Yes, app config, but beware people of writing config into beans.xml. >>> That is definitively in most cases not what you want.? CDI should not >>> define, where and how config is located and formatted. CDI should provide a >>> SPI, where config providers can publish the configured values, so it can be >>> injected wherever needed. E.g. some kind of producer, that can provide >>> multiple objects to be injected and can benefit from some kind of callback >>> mechanism would be sufficient... >>> >>> >>>> then environment config can be done at EE level (saying it has to >>>> support placeholders or any pre deployment processing). >>>> >>> ?Config is much more complex. There is no clear border what is >>> environment config or environment dependent and what not. This depends on >>> what kind of application you have deployed. As an example the email >>> address, where you send error messages, can be different depenending on the >>> stage/environment, but this is not EE related config entry. Also what an >>> environment is, is not a thing that you can define completely. So I agree >>> not to add this complexities to CDI, I would hide them between some kind of >>> "config provider", as mentioned above.? CDI does not need to know if the >>> config provided is environment dependent or not, its just what is visible >>> at a current runtime state... >>> >>> >>>> If you put something like ProjectStage in CDI it is great but then you >>>> have it in JSF, CDI and finally surely all specs...same as >>>> converters... >>>> >>> ?That was originally the idea, when doing a EE config JSR, but without >>> such standard. I agree, CDI is not the place to define them. >>> >>> >>> >>>> Config should really be split in: >>>> 1) spec dependent config -> spec.xml >>>> 2) *common* config (a bit like javax.annotation) for environment and >>>> external configuration -> Config JSR >>>> >>> ?Not 100% sure, if a get the point here... >>> >>> >>> >>> >>> >>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : >>> >>>> well sorry to pop in so late but here are my 2cts >>>> >>>> Config JSR is more about environment config IMHO and putting it in CDI >>>> doesn't make sense since more or more spec works without any other >>>> spec - CDI in our case. This mean CDI can't be the place but should >>>> just be the bridge for config JSR. Plus CDI config will surely highly >>>> be an application config first (beans.xml should be the place then) >>>> then environment config can be done at EE level (saying it has to >>>> support placeholders or any pre deployment processing). >>>> >>>> If you put something like ProjectStage in CDI it is great but then you >>>> have it in JSF, CDI and finally surely all specs...same as >>>> converters... >>>> >>>> Config should really be split in: >>>> 1) spec dependent config -> spec.xml >>>> 2) *common* config (a bit like javax.annotation) for environment and >>>> external configuration -> Config JSR >>>> >>>> wdyt? >>>> >>>> >>>> >>>> Romain Manni-Bucau >>>> Twitter: @rmannibucau >>>> Blog: http://rmannibucau.wordpress.com/ >>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>> Github: https://github.com/rmannibucau >>>> >>>> >>>> 2014-09-07 23:39 GMT+02:00 Werner Keil : >>>> > Sounds like an argument for a CDI module rather than a separate JSR >>>> then?;-) >>>> > >>>> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch >>>> wrote: >>>> >> >>>> >> I would not worry about CDI regarding licensing. Just the sentence >>>> was >>>> >> that Oracle does not want to have more ALv2 in addition to what is >>>> already >>>> >> there. So as long as we do things within CDI, no worries, I think. >>>> For new >>>> >> EE JSRs nevertheless this is a BIG issue and should be clarified by >>>> the EC! >>>> >> >>>> >> >>>> >> 2014-09-07 21:44 GMT+02:00 Werner Keil : >>>> >>> >>>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under >>>> ALv2 >>>> >>> as a dual-license, this was discussed by EC Members but both JCP EC >>>> and >>>> >>> Oracle Legal/PMO seems fine with it, and CDI is already an essential >>>> >>> building block to Java EE 6/7, hence used with Glassfish, too. I >>>> wasn't >>>> >>> involved in these discussions, but given CDI is especially liberal >>>> and fully >>>> >>> accepted by JCP formalities and license policies, I don't really >>>> see what >>>> >>> the problem wss for Anatole's JSR attempt (though I know, both >>>> Oracle and >>>> >>> other EC Members/companies don't always prefer this kind of >>>> licensing...;-) >>>> >>> >>>> >>> Werner >>>> >>> >>>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament < >>>> john.d.ament at gmail.com> >>>> >>> wrote: >>>> >>>> >>>> >>>> Ok, this mail has me more concerned than anything. Can you >>>> clarify this >>>> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. >>>> >>>> >>>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch >>> > >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Hi All >>>> >>>>> >>>> >>>>> unfortunately things seem quite complicated: >>>> >>>>> >>>> >>>>> first of all, similarities with Deltaspike are basically not >>>> >>>>> accidental. The concepts we developed in Credit Suisse are very >>>> similar to >>>> >>>>> Deltaspike, though Deltaspike was not yet born at that time. >>>> Fortunately we >>>> >>>>> ended up with a similar kind of solution. >>>> >>>>> filtering still can be done. My idea is to define some kind of >>>> >>>>> "configuration provider", which then is dynamically asked for >>>> configuration. >>>> >>>>> How the provider is internally organized, is completely >>>> transparent to CDI. >>>> >>>>> This enables to have multi-layered, complex config solutions work >>>> the same >>>> >>>>> (from a view point of CDI) like simple programmatic test >>>> configurations >>>> >>>>> during unit tests. The config provider still can support >>>> filtering and >>>> >>>>> dynamic resolution as commonly used in configuration systems. >>>> Similarly the >>>> >>>>> format is basically also not fixed. Of course, would a reference >>>> >>>>> implementation provide a set of functionalities, but I would >>>> definitively >>>> >>>>> not define the exact configuration mechanism as part of the CDI >>>> (or even a >>>> >>>>> EE config JSR). Another reason, beside complexity and time, is >>>> the fact that >>>> >>>>> different companies handle, store and manage configuration >>>> differently, so a >>>> >>>>> mechanism must be flexible enough to accommodate these, without >>>> adoption >>>> >>>>> rate will be low. Furthermore this flexibility also keeps doors >>>> open for use >>>> >>>>> cases we do not know yet. >>>> >>>>> Also we have to separate some basically two types of configuration >>>> >>>>> aspects: >>>> >>>>> >>>> >>>>> application config basically is injected into deployed >>>> components, but >>>> >>>>> basically only can affect deployment to the extend it can be >>>> managed and >>>> >>>>> injected by CDI. The basic architecture and design, how >>>> application servers >>>> >>>>> to load and deploy are basically not affected. This type of >>>> configuration >>>> >>>>> (mechanism) I see also as a possible addition to CDI, if we >>>> really fail to >>>> >>>>> do something in another JSR. With CDI going for a more modular >>>> design, even >>>> >>>>> basic configuration of CDI can be possible, given we have some >>>> kind of API, >>>> >>>>> we can access during CDI initialization. >>>> >>>>> On the other side deployment configuration affects directly how >>>> the >>>> >>>>> application server deploys the application. Configuration here >>>> would allow >>>> >>>>> to define datasources, EJBs, transactional aspects, security, >>>> persistence, >>>> >>>>> war and ear configurations etc. Basically everything you do as of >>>> today with >>>> >>>>> some kind of XML file, or annotation. Hereby enabling more >>>> flexibility into >>>> >>>>> the existing descriptors is relatively easy, but as mentioned by >>>> Mark, >>>> >>>>> constraint. Adding more flexibility raises other subtle problems. >>>> Imagine a >>>> >>>>> application module, e.g. a war, that defines everything it >>>> requires. There >>>> >>>>> is no need to configure anything more on server side (with spring >>>> you can do >>>> >>>>> this, with Java EE unfortunately not). But this has a severe >>>> consequence, it >>>> >>>>> would make the application really portable in the sense, that it >>>> can be >>>> >>>>> moved between different app servers (vendors) without any change >>>> (ideally). >>>> >>>>> As a result commercial profits of some vendor companies may be >>>> affected. I >>>> >>>>> think this is actually one of the key points, why things are >>>> getting so >>>> >>>>> complicated in that area. >>>> >>>>> >>>> >>>>> Legal aspects also were discussed. One of them is a possible legal >>>> >>>>> clash of ALv2 with GPL. This is the case already within >>>> Glassfish, but one >>>> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal >>>> department. At >>>> >>>>> the end we decided to use a BSD model. Even dual licensing >>>> BSD/ALv2 could >>>> >>>>> theoretically be an option. If you would choose ALv2, Oracle will >>>> not >>>> >>>>> include your RI into Glassfish, which is the RI for the EE >>>> Umbrella JSR, >>>> >>>>> meaning your JSR will not be included into EE8. So what should we >>>> do? I >>>> >>>>> don't have a good answer... >>>> >>>>> >>>> >>>>> So, I like to discuss configuration aspects here. Nevertheless if >>>> we >>>> >>>>> decide to add config aspects, be aware that we might only >>>> (mainly) support >>>> >>>>> application config, since everything else directly would impact >>>> other JSRs. >>>> >>>>> And that is obviously quite similar to what Apache Deltaspike is >>>> all about >>>> >>>>> ;-) >>>> >>>>> >>>> >>>>> Cheers, >>>> >>>>> Anatole >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : >>>> >>>>>> >>>> >>>>>> Yes, the config group also was (obviously) looking at DeltaSpikes >>>> >>>>>> config mechanism as well. >>>> >>>>>> There were others who wanted to go more into the 'filtering' >>>> approach >>>> >>>>>> as done on WebLogic servers (though not sure who else does that >>>> as well). >>>> >>>>>> You know, having all the XML configs like WEB-INF/web.xml >>>> containing >>>> >>>>>> placeholders and the real values only get placed in there at >>>> deployment >>>> >>>>>> time. I personally find this approach a bit limited from a >>>> technical >>>> >>>>>> perspective and it already didn't work out for me when using >>>> WebLogic (what >>>> >>>>>> about changing a configured value after the deployment was done? >>>> What about >>>> >>>>>> security? Having passwords in web.xml, unit testing, ...). >>>> >>>>>> There are of course also other approaches which all might have >>>> strong >>>> >>>>>> sides and would have needed to get discussed. >>>> >>>>>> >>>> >>>>>> But utterly the problem seems to have been legal reasons. We even >>>> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF >>>> project with >>>> >>>>>> substantial support and participation from the JBoss, DeltaSpike >>>> and TomEE >>>> >>>>>> communities. >>>> >>>>>> >>>> >>>>>> Anyway, the time will come when we will resurrect this effort. >>>> >>>>>> >>>> >>>>>> LieGrue, >>>> >>>>>> strub >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil >>>> >>>>>> wrote: >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Yep, it contains a simple but extendable notion of ProjectStage, >>>> >>>>>> too;-) >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament < >>>> john.d.ament at gmail.com> >>>> >>>>>> wrote: >>>> >>>>>> >>>> >>>>>> Anatole, >>>> >>>>>> >>>> >>>>>> I'm wondering if some of your configuration description falls >>>> under >>>> >>>>>> what was put together in DeltaSpike? >>>> >>>>>> >>>> >>>>>> http://deltaspike.apache.org/configuration.html >>>> >>>>>> >>>> >>>>>> John >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch < >>>> atsticks at gmail.com> >>>> >>>>>> wrote: >>>> >>>>>> >>>> >>>>>> Staging is not a question of xml or not xml (the "format" of >>>> config). >>>> >>>>>> You can do staged config also using xml, or based on a database >>>> or json >>>> >>>>>> config service. Staging as well as, more generally speaking, >>>> environment >>>> >>>>>> dependent config is more like to select/filter the right config >>>> that targets >>>> >>>>>> the current (runtime) environment. This might include stages, >>>> but also many >>>> >>>>>> other aspects are feasible and common (server, tier, ear, war, >>>> tenant ...). >>>> >>>>>> Since these aspects are per se very complex, it might be >>>> advisable to leave >>>> >>>>>> them out of any spec (even a dedicated config JSR would probably >>>> not be >>>> >>>>>> capable of covering these within the relatively short EE >>>> timeframe)... >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil : >>>> >>>>>> >>>> >>>>>> Jens/all, >>>> >>>>>> >>>> >>>>>> A sort of "staging" already was possible using CDI earlier, see >>>> >>>>>> examples like this: >>>> >>>>>> >>>> >>>>>> >>>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >>>> >>>>>> >>>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond the >>>> >>>>>> primitive, hard-coded JSF enum. >>>> >>>>>> >>>> >>>>>> If that works without XML, while still allowing flexible >>>> configuration >>>> >>>>>> for different stages or to add and "inject" additional stages >>>> maybe even on >>>> >>>>>> a tenant basis (for Cloud scenarios) I could see something like >>>> that work >>>> >>>>>> without XML. In the Multiconf project we managed to code >>>> everything in >>>> >>>>>> Python, and similar to Puppet or Chef you can configure and >>>> deploy multiple >>>> >>>>>> environments with it, Java EE, Spring or Play! several of them >>>> are >>>> >>>>>> configured this way and it requires no XML (where the container >>>> needs such >>>> >>>>>> files, the framework generates them;-) >>>> >>>>>> >>>> >>>>>> Werner >>>> >>>>>> >>>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, < >>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole >>>> Tresch) >>>> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >>>> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>>> >>>>>> (Anatole Tresch (JIRA)) >>>> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) >>>> >>>>>> >>>> >>>>>> ------------------------------ >>>> >>>>>> >>>> >>>>>> Message: 4 >>>> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >>>> >>>>>> From: Jens Schumann >>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... >>>> >>>>>> To: Anatole Tresch , Antonio Goncalves >>>> >>>>>> >>>> >>>>>> Cc: cdi-dev >>>> >>>>>> Message-ID: >>>> >>>>>> Content-Type: text/plain; charset="windows-1252" >>>> >>>>>> >>>> >>>>>> I can confirm that this approach works very well. We are using a >>>> >>>>>> similar approach a couple of years now, and I love the >>>> simplicity that comes >>>> >>>>>> with portable extensions and @Producer methods. See our public >>>> version here >>>> >>>>>> [1] (works since early CDI 1.0 days) . >>>> >>>>>> >>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier >>>> @Property. >>>> >>>>>> We support default values and type conversation for primitives >>>> and >>>> >>>>>> everything that has a string based constructor. The property >>>> source can be >>>> >>>>>> anything, from property files (default) to databases or xml >>>> files. For >>>> >>>>>> examples see tests here [2]. >>>> >>>>>> >>>> >>>>>> Nevertheless I am not sure if this should be part of an future >>>> CDI >>>> >>>>>> spec. My concerns include the bloat argument, of course. But the >>>> main reason >>>> >>>>>> relates to the fact that we have almost everything in the >>>> current CDI spec >>>> >>>>>> already. >>>> >>>>>> >>>> >>>>>> Right now I am quite happy with an custom portable extension >>>> that does >>>> >>>>>> everything for me. At the time we implemented the extension we >>>> realised that >>>> >>>>>> the "hard part" was writing an extension that links a qualified >>>> "optional >>>> >>>>>> injection point" with an @Producer method while supporting code >>>> based >>>> >>>>>> default values. Luckily I had Arne in my team who did that >>>> within a few >>>> >>>>>> minutes. >>>> >>>>>> >>>> >>>>>> Because of this experience I would propose that we simplify >>>> extension >>>> >>>>>> development such that "optional injection points" may be linked >>>> to @Produces >>>> >>>>>> values easily. Additionally we have to solve a few more >>>> integration issues >>>> >>>>>> (e.g. read-only DB access should be available during CDI >>>> startup). >>>> >>>>>> Everything else should be provided by portable extensions (e.g. >>>> via >>>> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. >>>> >>>>>> >>>> >>>>>> Jens >>>> >>>>>> [1] >>>> >>>>>> >>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>>> >>>>>> [2] >>>> >>>>>> >>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>>> >>>>>> >>>> >>>>>> Von: Anatole Tresch >>> atsticks at gmail.com>> >>>> >>>>>> Datum: Friday 5 September 2014 21:22 >>>> >>>>>> An: Antonio Goncalves >>>> >>>>>> >>> >> >>>> >>>>>> Cc: CDI-Dev >>> cdi-dev at lists.jboss.org>> >>>> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... >>>> >>>>>> >>>> >>>>>> Hi all, >>>> >>>>>> >>>> >>>>>> I would not like to add an XML "bloated" mechanism as part of >>>> CDI 2.0. >>>> >>>>>> Spontaneously I would propose a more CDI like things like: >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> * Adding a @Configured annotation (basically a qualifier). >>>> This >>>> >>>>>> can be in addition to @Inject and would allow to inject >>>> "configured" values. >>>> >>>>>> * Since configuration can change we may think of a (CDI) >>>> >>>>>> event/reinject mechanism based on config changes. By default, >>>> this is >>>> >>>>>> switched off and we can discuss how it would be activated, e.g. >>>> by an >>>> >>>>>> additional flag settable with the @Configured annotation, or an >>>> additional >>>> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon >>>> framework), or both. >>>> >>>>>> * Hereby configured values theoretically behave similar as >>>> all >>>> >>>>>> other injection points. They also can be qualified (the aspect >>>> of scopes, I >>>> >>>>>> did not yet have time to think about). The only difference is, >>>> that they are >>>> >>>>>> satisified using the configuration "system". >>>> >>>>>> * The configuration "source" itself could in the extreme >>>> simplest >>>> >>>>>> way be a Provider>. The CDI spec should not >>>> care about >>>> >>>>>> how this map is provided (XML, DB, overrides, etc). This still >>>> can be >>>> >>>>>> standardized later. As long as the ConfigurationSource SPI is >>>> defined, >>>> >>>>>> companies still can hook in the logic and level of configuration >>>> abstraction >>>> >>>>>> they need. >>>> >>>>>> * Of course, since not only Strings can be injected, we need >>>> some >>>> >>>>>> conversion or adapter logic as basically outlined in my blog. >>>> Also here we >>>> >>>>>> can add a simple SPI and let the details to the RI. >>>> >>>>>> >>>> >>>>>> Summarizing a >>>> >>>>>> >>>> >>>>>> * @Configured annotation >>>> >>>>>> * some kind of change event >>>> >>>>>> * a ConfigurationSource extends Provider> >>>> >>>>>> * a conversion mechanism from String to T. >>>> >>>>>> >>>> >>>>>> we get a full fledged configuration mechanism that leverages CDI. >>>> >>>>>> >>>> >>>>>> That would be my idea basically. WDYT? I will try to work that >>>> out in >>>> >>>>>> more details. Basically it should be implementable even with the >>>> CDI >>>> >>>>>> mechanism already in place with CDI 1.1. >>>> >>>>>> >>>> >>>>>> Best, >>>> >>>>>> Anatole >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >>>> >>>>>> >>> >>: >>>> >>>>>> One wise man* once said "EJB was a hype specification, we added >>>> too >>>> >>>>>> many things to it, it became bloated. The next hype >>>> specifications are >>>> >>>>>> JAX-RS and CDI, careful with them" >>>> >>>>>> >>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup being >>>> >>>>>> bloated. >>>> >>>>>> >>>> >>>>>> Antonio >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> *David Blevin >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand >>>> >>>>>> > >>>> wrote: >>>> >>>>>> Hi all, >>>> >>>>>> >>>> >>>>>> You may have followed the rise and fall of the Java Config JSR >>>> >>>>>> ( >>>> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >>>> ). >>>> >>>>>> Anatole in CC was leading this initiative and I proposed him to >>>> join >>>> >>>>>> us and explore if some part of his late-JSR could be done in CDI. >>>> >>>>>> >>>> >>>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 >>>> or >>>> >>>>>> related solution. If we achieve to have a majority of specs to >>>> integrate >>>> >>>>>> with CDI, our configuration solution would therefore become a >>>> configuration >>>> >>>>>> system for all spec based on CDI 2.0. >>>> >>>>>> >>>> >>>>>> 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. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Antonio Goncalves >>>> >>>>>> Software architect, Java Champion and Pluralsight author >>>> >>>>>> >>>> >>>>>> Web site | >>>> >>>>>> Twitter | >>>> >>>>>> LinkedIn | >>>> >>>>>> Pluralsight< >>>> http://pluralsight.com/training/Authors/Details/antonio-goncalves> >>>> >>>>>> | Paris JUG | Devoxx France< >>>> http://www.devoxx.fr> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> 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. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Anatole Tresch >>>> >>>>>> Java Lead Engineer, JSR Spec Lead >>>> >>>>>> Gl?rnischweg 10 >>>> >>>>>> CH - 8620 Wetzikon >>>> >>>>>> >>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>>> >>>>>> Twitter: @atsticks >>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>> >>>>>> Google: atsticks >>>> >>>>>> Mobile +41-76 344 62 79 >>>> >>>>>> -------------- next part -------------- >>>> >>>>>> An HTML attachment was scrubbed... >>>> >>>>>> URL: >>>> >>>>>> >>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>>> >>>>>> *************************************** >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> 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. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Anatole Tresch >>>> >>>>>> Java Lead Engineer, JSR Spec Lead >>>> >>>>>> Gl?rnischweg 10 >>>> >>>>>> CH - 8620 Wetzikon >>>> >>>>>> >>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>>> >>>>>> Twitter: @atsticks >>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>> >>>>>> Google: atsticks >>>> >>>>>> Mobile +41-76 344 62 79 >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> 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. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> 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. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> -- >>>> >>>>> Anatole Tresch >>>> >>>>> Java Lead Engineer, JSR Spec Lead >>>> >>>>> Gl?rnischweg 10 >>>> >>>>> CH - 8620 Wetzikon >>>> >>>>> >>>> >>>>> Switzerland, Europe Zurich, GMT+1 >>>> >>>>> Twitter: @atsticks >>>> >>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>> >>>>> Google: atsticks >>>> >>>>> Mobile +41-76 344 62 79 >>>> >>>> >>>> >>>> >>>> >>> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Anatole Tresch >>>> >> Java Lead Engineer, JSR Spec Lead >>>> >> Gl?rnischweg 10 >>>> >> CH - 8620 Wetzikon >>>> >> >>>> >> Switzerland, Europe Zurich, GMT+1 >>>> >> Twitter: @atsticks >>>> >> Blogs: http://javaremarkables.blogspot.ch/ >>>> >> Google: atsticks >>>> >> Mobile +41-76 344 62 79 >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > 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. >>>> >>> >>> >>> >>> -- >>> *Anatole Tresch* >>> Java Lead Engineer, JSR Spec Lead >>> Gl?rnischweg 10 >>> CH - 8620 Wetzikon >>> >>> *Switzerland, Europe Zurich, GMT+1* >>> *Twitter: @atsticks* >>> *Blogs: **http://javaremarkables.blogspot.ch/ >>> * >>> >>> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* >>> >> >> _______________________________________________ >> 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. >> > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/fe7479a2/attachment-0001.html From rmannibucau at gmail.com Mon Sep 8 05:51:21 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 8 Sep 2014 11:51:21 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: @Antonio: -1 for an appendix, bean validation is the example it is broken. Idea is awesome, everybody liked it so it was added -> great. Here everybody already agrees it is good so no need of "staging" phase IMHO. BV appendix was not the API used so it broke apps using it. SO using proprietary stuff is the same, it basically mean an appendix spec for something not under discussion (regarding its need) is IMHO useless. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-09-08 10:29 GMT+02:00 Werner Keil : > Hi, > > If it's not really usable as API or annotation I don't see much value in > adding some "how to" or intent for the future into the Spec Document. > > If it was to become a part of CDI 2, there's nothing against optionality > like MEEP 8 or JSR 363 already practice on the SE/EE side either. > > Agorava/DeltaSpike demonstrate how true modularity work, similar to the JSRs > mentioned above, where you have multiple module JARs/bundles instead of a > big monolithic one. Some JSRs like Batch also declared separate "annotation" > modules, so that's what CDI 2 should also do if it was a feature Inside of > it. > Calling some features optional if they're not used by every implementation > allows them to chose. That was also the main value of keeping @Inject a > separate "module" under CDI. It was never included into a JDK but used > independently. > > The core of a Config module would ideally work in SE, but CDI 2 already > declared an aim to have some modules work under SE. > > Werner > > Am 08.09.2014 09:47 schrieb "Antonio Goncalves" > : > >> Hi all, >> >> I really have some concerns about adding configuration into CDI but I can >> see benefits too. And what about adding it... and not adding it at the same >> time ? In Bean Validation 1.0, the Expert Group decided not to include >> method-level validation in the spec (it was included in 1.1). But what they >> did is to add it as a proposal in the Appendix. >> >> If we feel some configuration should get in, why not have a proposal in >> the Appendix of CDI 2.0 ? It could then be implemented by Weld (and >> OpenWebBeans if they feel like it). And then, if it's successful and things >> get easier, get its own JSR for Java EE 9. >> >> WDYT ? >> >> Antonio >> >> On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau >> wrote: >>> >>> Hmm >>> >>> I see config jsr as a jse spec which would allow EE injections in config >>> components in EE containers (exactly like jbatch). >>> >>> This way it can be used without any container or with any container >>> easily. Only limit will be to not do something cdi/known containers will not >>> support I think. >>> >>> Not sure EE side is needed today, a lot can already be done without it >>> and it can be enhanced later adding some integration words. >>> >>> Le 8 sept. 2014 00:01, "Anatole Tresch" a ?crit : >>> >>>> Hi Romain >>>> >>>> just a few remarks inline... >>>> >>>> Summarizing >>>> 1) injection of values, reinjection, feedback on config changes can all >>>> be done with already existing features (producers, extensions). >>>> 2) configuring/bootstrapping CDI itself, e.g. configuration, is targeted >>>> with CDI 2.0 (see spec failing) >>>> >>>> So basically we could try to look if there is enough interest to >>>> standardize configuration in a more general way. For deployment aspects we >>>> need an EE JSR, for the rest, another SE standard may be an option as >>>> well... tbd... >>>> >>>> -Anatole >>>> >>>> >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : >>>>> >>>>> well sorry to pop in so late but here are my 2cts >>>> >>>> easy ;) >>>> >>>>> >>>>> Config JSR is more about environment config IMHO and putting it in CDI >>>>> doesn't make sense since more or more spec works without any other >>>>> spec - CDI in our case. >>>> >>>> CDI even with some config mechanism added would still work "standalone". >>>> >>>> >>>>> >>>>> This mean CDI can't be the place but should >>>>> just be the bridge for config JSR. >>>> >>>> As I suggested as well. >>>> >>>> >>>>> >>>>> Plus CDI config will surely highly >>>>> be an application config first (beans.xml should be the place then) >>>> >>>> Yes, app config, but beware people of writing config into beans.xml. >>>> That is definitively in most cases not what you want. CDI should not define, >>>> where and how config is located and formatted. CDI should provide a SPI, >>>> where config providers can publish the configured values, so it can be >>>> injected wherever needed. E.g. some kind of producer, that can provide >>>> multiple objects to be injected and can benefit from some kind of callback >>>> mechanism would be sufficient... >>>> >>>>> >>>>> then environment config can be done at EE level (saying it has to >>>>> support placeholders or any pre deployment processing). >>>> >>>> Config is much more complex. There is no clear border what is >>>> environment config or environment dependent and what not. This depends on >>>> what kind of application you have deployed. As an example the email address, >>>> where you send error messages, can be different depenending on the >>>> stage/environment, but this is not EE related config entry. Also what an >>>> environment is, is not a thing that you can define completely. So I agree >>>> not to add this complexities to CDI, I would hide them between some kind of >>>> "config provider", as mentioned above. CDI does not need to know if the >>>> config provided is environment dependent or not, its just what is visible at >>>> a current runtime state... >>>> >>>>> >>>>> If you put something like ProjectStage in CDI it is great but then you >>>>> have it in JSF, CDI and finally surely all specs...same as >>>>> converters... >>>> >>>> That was originally the idea, when doing a EE config JSR, but without >>>> such standard. I agree, CDI is not the place to define them. >>>> >>>> >>>>> >>>>> Config should really be split in: >>>>> 1) spec dependent config -> spec.xml >>>>> 2) *common* config (a bit like javax.annotation) for environment and >>>>> external configuration -> Config JSR >>>> >>>> Not 100% sure, if a get the point here... >>>> >>>> >>>> >>>> >>>> >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : >>>>> >>>>> well sorry to pop in so late but here are my 2cts >>>>> >>>>> Config JSR is more about environment config IMHO and putting it in CDI >>>>> doesn't make sense since more or more spec works without any other >>>>> spec - CDI in our case. This mean CDI can't be the place but should >>>>> just be the bridge for config JSR. Plus CDI config will surely highly >>>>> be an application config first (beans.xml should be the place then) >>>>> then environment config can be done at EE level (saying it has to >>>>> support placeholders or any pre deployment processing). >>>>> >>>>> If you put something like ProjectStage in CDI it is great but then you >>>>> have it in JSF, CDI and finally surely all specs...same as >>>>> converters... >>>>> >>>>> Config should really be split in: >>>>> 1) spec dependent config -> spec.xml >>>>> 2) *common* config (a bit like javax.annotation) for environment and >>>>> external configuration -> Config JSR >>>>> >>>>> wdyt? >>>>> >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> Twitter: @rmannibucau >>>>> Blog: http://rmannibucau.wordpress.com/ >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>> Github: https://github.com/rmannibucau >>>>> >>>>> >>>>> 2014-09-07 23:39 GMT+02:00 Werner Keil : >>>>> > Sounds like an argument for a CDI module rather than a separate JSR >>>>> > then?;-) >>>>> > >>>>> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch >>>>> > wrote: >>>>> >> >>>>> >> I would not worry about CDI regarding licensing. Just the sentence >>>>> >> was >>>>> >> that Oracle does not want to have more ALv2 in addition to what is >>>>> >> already >>>>> >> there. So as long as we do things within CDI, no worries, I think. >>>>> >> For new >>>>> >> EE JSRs nevertheless this is a BIG issue and should be clarified by >>>>> >> the EC! >>>>> >> >>>>> >> >>>>> >> 2014-09-07 21:44 GMT+02:00 Werner Keil : >>>>> >>> >>>>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under >>>>> >>> ALv2 >>>>> >>> as a dual-license, this was discussed by EC Members but both JCP EC >>>>> >>> and >>>>> >>> Oracle Legal/PMO seems fine with it, and CDI is already an >>>>> >>> essential >>>>> >>> building block to Java EE 6/7, hence used with Glassfish, too. I >>>>> >>> wasn't >>>>> >>> involved in these discussions, but given CDI is especially liberal >>>>> >>> and fully >>>>> >>> accepted by JCP formalities and license policies, I don't really >>>>> >>> see what >>>>> >>> the problem wss for Anatole's JSR attempt (though I know, both >>>>> >>> Oracle and >>>>> >>> other EC Members/companies don't always prefer this kind of >>>>> >>> licensing...;-) >>>>> >>> >>>>> >>> Werner >>>>> >>> >>>>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament >>>>> >>> >>>>> >>> wrote: >>>>> >>>> >>>>> >>>> Ok, this mail has me more concerned than anything. Can you >>>>> >>>> clarify this >>>>> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. >>>>> >>>> >>>>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch >>>>> >>>> >>>>> >>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi All >>>>> >>>>> >>>>> >>>>> unfortunately things seem quite complicated: >>>>> >>>>> >>>>> >>>>> first of all, similarities with Deltaspike are basically not >>>>> >>>>> accidental. The concepts we developed in Credit Suisse are very >>>>> >>>>> similar to >>>>> >>>>> Deltaspike, though Deltaspike was not yet born at that time. >>>>> >>>>> Fortunately we >>>>> >>>>> ended up with a similar kind of solution. >>>>> >>>>> filtering still can be done. My idea is to define some kind of >>>>> >>>>> "configuration provider", which then is dynamically asked for >>>>> >>>>> configuration. >>>>> >>>>> How the provider is internally organized, is completely >>>>> >>>>> transparent to CDI. >>>>> >>>>> This enables to have multi-layered, complex config solutions work >>>>> >>>>> the same >>>>> >>>>> (from a view point of CDI) like simple programmatic test >>>>> >>>>> configurations >>>>> >>>>> during unit tests. The config provider still can support >>>>> >>>>> filtering and >>>>> >>>>> dynamic resolution as commonly used in configuration systems. >>>>> >>>>> Similarly the >>>>> >>>>> format is basically also not fixed. Of course, would a reference >>>>> >>>>> implementation provide a set of functionalities, but I would >>>>> >>>>> definitively >>>>> >>>>> not define the exact configuration mechanism as part of the CDI >>>>> >>>>> (or even a >>>>> >>>>> EE config JSR). Another reason, beside complexity and time, is >>>>> >>>>> the fact that >>>>> >>>>> different companies handle, store and manage configuration >>>>> >>>>> differently, so a >>>>> >>>>> mechanism must be flexible enough to accommodate these, without >>>>> >>>>> adoption >>>>> >>>>> rate will be low. Furthermore this flexibility also keeps doors >>>>> >>>>> open for use >>>>> >>>>> cases we do not know yet. >>>>> >>>>> Also we have to separate some basically two types of >>>>> >>>>> configuration >>>>> >>>>> aspects: >>>>> >>>>> >>>>> >>>>> application config basically is injected into deployed >>>>> >>>>> components, but >>>>> >>>>> basically only can affect deployment to the extend it can be >>>>> >>>>> managed and >>>>> >>>>> injected by CDI. The basic architecture and design, how >>>>> >>>>> application servers >>>>> >>>>> to load and deploy are basically not affected. This type of >>>>> >>>>> configuration >>>>> >>>>> (mechanism) I see also as a possible addition to CDI, if we >>>>> >>>>> really fail to >>>>> >>>>> do something in another JSR. With CDI going for a more modular >>>>> >>>>> design, even >>>>> >>>>> basic configuration of CDI can be possible, given we have some >>>>> >>>>> kind of API, >>>>> >>>>> we can access during CDI initialization. >>>>> >>>>> On the other side deployment configuration affects directly how >>>>> >>>>> the >>>>> >>>>> application server deploys the application. Configuration here >>>>> >>>>> would allow >>>>> >>>>> to define datasources, EJBs, transactional aspects, security, >>>>> >>>>> persistence, >>>>> >>>>> war and ear configurations etc. Basically everything you do as of >>>>> >>>>> today with >>>>> >>>>> some kind of XML file, or annotation. Hereby enabling more >>>>> >>>>> flexibility into >>>>> >>>>> the existing descriptors is relatively easy, but as mentioned by >>>>> >>>>> Mark, >>>>> >>>>> constraint. Adding more flexibility raises other subtle problems. >>>>> >>>>> Imagine a >>>>> >>>>> application module, e.g. a war, that defines everything it >>>>> >>>>> requires. There >>>>> >>>>> is no need to configure anything more on server side (with spring >>>>> >>>>> you can do >>>>> >>>>> this, with Java EE unfortunately not). But this has a severe >>>>> >>>>> consequence, it >>>>> >>>>> would make the application really portable in the sense, that it >>>>> >>>>> can be >>>>> >>>>> moved between different app servers (vendors) without any change >>>>> >>>>> (ideally). >>>>> >>>>> As a result commercial profits of some vendor companies may be >>>>> >>>>> affected. I >>>>> >>>>> think this is actually one of the key points, why things are >>>>> >>>>> getting so >>>>> >>>>> complicated in that area. >>>>> >>>>> >>>>> >>>>> Legal aspects also were discussed. One of them is a possible >>>>> >>>>> legal >>>>> >>>>> clash of ALv2 with GPL. This is the case already within >>>>> >>>>> Glassfish, but one >>>>> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal >>>>> >>>>> department. At >>>>> >>>>> the end we decided to use a BSD model. Even dual licensing >>>>> >>>>> BSD/ALv2 could >>>>> >>>>> theoretically be an option. If you would choose ALv2, Oracle will >>>>> >>>>> not >>>>> >>>>> include your RI into Glassfish, which is the RI for the EE >>>>> >>>>> Umbrella JSR, >>>>> >>>>> meaning your JSR will not be included into EE8. So what should we >>>>> >>>>> do? I >>>>> >>>>> don't have a good answer... >>>>> >>>>> >>>>> >>>>> So, I like to discuss configuration aspects here. Nevertheless if >>>>> >>>>> we >>>>> >>>>> decide to add config aspects, be aware that we might only >>>>> >>>>> (mainly) support >>>>> >>>>> application config, since everything else directly would impact >>>>> >>>>> other JSRs. >>>>> >>>>> And that is obviously quite similar to what Apache Deltaspike is >>>>> >>>>> all about >>>>> >>>>> ;-) >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Anatole >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : >>>>> >>>>>> >>>>> >>>>>> Yes, the config group also was (obviously) looking at >>>>> >>>>>> DeltaSpikes >>>>> >>>>>> config mechanism as well. >>>>> >>>>>> There were others who wanted to go more into the 'filtering' >>>>> >>>>>> approach >>>>> >>>>>> as done on WebLogic servers (though not sure who else does that >>>>> >>>>>> as well). >>>>> >>>>>> You know, having all the XML configs like WEB-INF/web.xml >>>>> >>>>>> containing >>>>> >>>>>> placeholders and the real values only get placed in there at >>>>> >>>>>> deployment >>>>> >>>>>> time. I personally find this approach a bit limited from a >>>>> >>>>>> technical >>>>> >>>>>> perspective and it already didn't work out for me when using >>>>> >>>>>> WebLogic (what >>>>> >>>>>> about changing a configured value after the deployment was done? >>>>> >>>>>> What about >>>>> >>>>>> security? Having passwords in web.xml, unit testing, ...). >>>>> >>>>>> There are of course also other approaches which all might have >>>>> >>>>>> strong >>>>> >>>>>> sides and would have needed to get discussed. >>>>> >>>>>> >>>>> >>>>>> But utterly the problem seems to have been legal reasons. We >>>>> >>>>>> even >>>>> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF >>>>> >>>>>> project with >>>>> >>>>>> substantial support and participation from the JBoss, DeltaSpike >>>>> >>>>>> and TomEE >>>>> >>>>>> communities. >>>>> >>>>>> >>>>> >>>>>> Anyway, the time will come when we will resurrect this effort. >>>>> >>>>>> >>>>> >>>>>> LieGrue, >>>>> >>>>>> strub >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil >>>>> >>>>>> wrote: >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Yep, it contains a simple but extendable notion of ProjectStage, >>>>> >>>>>> too;-) >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament >>>>> >>>>>> >>>>> >>>>>> wrote: >>>>> >>>>>> >>>>> >>>>>> Anatole, >>>>> >>>>>> >>>>> >>>>>> I'm wondering if some of your configuration description falls >>>>> >>>>>> under >>>>> >>>>>> what was put together in DeltaSpike? >>>>> >>>>>> >>>>> >>>>>> http://deltaspike.apache.org/configuration.html >>>>> >>>>>> >>>>> >>>>>> John >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch >>>>> >>>>>> >>>>> >>>>>> wrote: >>>>> >>>>>> >>>>> >>>>>> Staging is not a question of xml or not xml (the "format" of >>>>> >>>>>> config). >>>>> >>>>>> You can do staged config also using xml, or based on a database >>>>> >>>>>> or json >>>>> >>>>>> config service. Staging as well as, more generally speaking, >>>>> >>>>>> environment >>>>> >>>>>> dependent config is more like to select/filter the right config >>>>> >>>>>> that targets >>>>> >>>>>> the current (runtime) environment. This might include stages, >>>>> >>>>>> but also many >>>>> >>>>>> other aspects are feasible and common (server, tier, ear, war, >>>>> >>>>>> tenant ...). >>>>> >>>>>> Since these aspects are per se very complex, it might be >>>>> >>>>>> advisable to leave >>>>> >>>>>> them out of any spec (even a dedicated config JSR would probably >>>>> >>>>>> not be >>>>> >>>>>> capable of covering these within the relatively short EE >>>>> >>>>>> timeframe)... >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil : >>>>> >>>>>> >>>>> >>>>>> Jens/all, >>>>> >>>>>> >>>>> >>>>>> A sort of "staging" already was possible using CDI earlier, see >>>>> >>>>>> examples like this: >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >>>>> >>>>>> >>>>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond the >>>>> >>>>>> primitive, hard-coded JSF enum. >>>>> >>>>>> >>>>> >>>>>> If that works without XML, while still allowing flexible >>>>> >>>>>> configuration >>>>> >>>>>> for different stages or to add and "inject" additional stages >>>>> >>>>>> maybe even on >>>>> >>>>>> a tenant basis (for Cloud scenarios) I could see something like >>>>> >>>>>> that work >>>>> >>>>>> without XML. In the Multiconf project we managed to code >>>>> >>>>>> everything in >>>>> >>>>>> Python, and similar to Puppet or Chef you can configure and >>>>> >>>>>> deploy multiple >>>>> >>>>>> environments with it, Java EE, Spring or Play! several of them >>>>> >>>>>> are >>>>> >>>>>> configured this way and it requires no XML (where the container >>>>> >>>>>> needs such >>>>> >>>>>> files, the framework generates them;-) >>>>> >>>>>> >>>>> >>>>>> Werner >>>>> >>>>>> >>>>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, >>>>> >>>>>> >>>>> >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole >>>>> >>>>>> Tresch) >>>>> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >>>>> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>>>> >>>>>> (Anatole Tresch (JIRA)) >>>>> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) >>>>> >>>>>> >>>>> >>>>>> ------------------------------ >>>>> >>>>>> >>>>> >>>>>> Message: 4 >>>>> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >>>>> >>>>>> From: Jens Schumann >>>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... >>>>> >>>>>> To: Anatole Tresch , Antonio Goncalves >>>>> >>>>>> >>>>> >>>>>> Cc: cdi-dev >>>>> >>>>>> Message-ID: >>>>> >>>>>> Content-Type: text/plain; charset="windows-1252" >>>>> >>>>>> >>>>> >>>>>> I can confirm that this approach works very well. We are using a >>>>> >>>>>> similar approach a couple of years now, and I love the >>>>> >>>>>> simplicity that comes >>>>> >>>>>> with portable extensions and @Producer methods. See our public >>>>> >>>>>> version here >>>>> >>>>>> [1] (works since early CDI 1.0 days) . >>>>> >>>>>> >>>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier >>>>> >>>>>> @Property. >>>>> >>>>>> We support default values and type conversation for primitives >>>>> >>>>>> and >>>>> >>>>>> everything that has a string based constructor. The property >>>>> >>>>>> source can be >>>>> >>>>>> anything, from property files (default) to databases or xml >>>>> >>>>>> files. For >>>>> >>>>>> examples see tests here [2]. >>>>> >>>>>> >>>>> >>>>>> Nevertheless I am not sure if this should be part of an future >>>>> >>>>>> CDI >>>>> >>>>>> spec. My concerns include the bloat argument, of course. But the >>>>> >>>>>> main reason >>>>> >>>>>> relates to the fact that we have almost everything in the >>>>> >>>>>> current CDI spec >>>>> >>>>>> already. >>>>> >>>>>> >>>>> >>>>>> Right now I am quite happy with an custom portable extension >>>>> >>>>>> that does >>>>> >>>>>> everything for me. At the time we implemented the extension we >>>>> >>>>>> realised that >>>>> >>>>>> the "hard part" was writing an extension that links a qualified >>>>> >>>>>> "optional >>>>> >>>>>> injection point" with an @Producer method while supporting code >>>>> >>>>>> based >>>>> >>>>>> default values. Luckily I had Arne in my team who did that >>>>> >>>>>> within a few >>>>> >>>>>> minutes. >>>>> >>>>>> >>>>> >>>>>> Because of this experience I would propose that we simplify >>>>> >>>>>> extension >>>>> >>>>>> development such that "optional injection points" may be linked >>>>> >>>>>> to @Produces >>>>> >>>>>> values easily. Additionally we have to solve a few more >>>>> >>>>>> integration issues >>>>> >>>>>> (e.g. read-only DB access should be available during CDI >>>>> >>>>>> startup). >>>>> >>>>>> Everything else should be provided by portable extensions (e.g. >>>>> >>>>>> via >>>>> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. >>>>> >>>>>> >>>>> >>>>>> Jens >>>>> >>>>>> [1] >>>>> >>>>>> >>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>>>> >>>>>> [2] >>>>> >>>>>> >>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>>>> >>>>>> >>>>> >>>>>> Von: Anatole Tresch >>>>> >>>>>> > >>>>> >>>>>> Datum: Friday 5 September 2014 21:22 >>>>> >>>>>> An: Antonio Goncalves >>>>> >>>>>> >>>>> >>>>>> > >>>>> >>>>>> Cc: CDI-Dev >>>>> >>>>>> > >>>>> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... >>>>> >>>>>> >>>>> >>>>>> Hi all, >>>>> >>>>>> >>>>> >>>>>> I would not like to add an XML "bloated" mechanism as part of >>>>> >>>>>> CDI 2.0. >>>>> >>>>>> Spontaneously I would propose a more CDI like things like: >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> * Adding a @Configured annotation (basically a qualifier). >>>>> >>>>>> This >>>>> >>>>>> can be in addition to @Inject and would allow to inject >>>>> >>>>>> "configured" values. >>>>> >>>>>> * Since configuration can change we may think of a (CDI) >>>>> >>>>>> event/reinject mechanism based on config changes. By default, >>>>> >>>>>> this is >>>>> >>>>>> switched off and we can discuss how it would be activated, e.g. >>>>> >>>>>> by an >>>>> >>>>>> additional flag settable with the @Configured annotation, or an >>>>> >>>>>> additional >>>>> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon >>>>> >>>>>> framework), or both. >>>>> >>>>>> * Hereby configured values theoretically behave similar as >>>>> >>>>>> all >>>>> >>>>>> other injection points. They also can be qualified (the aspect >>>>> >>>>>> of scopes, I >>>>> >>>>>> did not yet have time to think about). The only difference is, >>>>> >>>>>> that they are >>>>> >>>>>> satisified using the configuration "system". >>>>> >>>>>> * The configuration "source" itself could in the extreme >>>>> >>>>>> simplest >>>>> >>>>>> way be a Provider>. The CDI spec should not >>>>> >>>>>> care about >>>>> >>>>>> how this map is provided (XML, DB, overrides, etc). This still >>>>> >>>>>> can be >>>>> >>>>>> standardized later. As long as the ConfigurationSource SPI is >>>>> >>>>>> defined, >>>>> >>>>>> companies still can hook in the logic and level of configuration >>>>> >>>>>> abstraction >>>>> >>>>>> they need. >>>>> >>>>>> * Of course, since not only Strings can be injected, we need >>>>> >>>>>> some >>>>> >>>>>> conversion or adapter logic as basically outlined in my blog. >>>>> >>>>>> Also here we >>>>> >>>>>> can add a simple SPI and let the details to the RI. >>>>> >>>>>> >>>>> >>>>>> Summarizing a >>>>> >>>>>> >>>>> >>>>>> * @Configured annotation >>>>> >>>>>> * some kind of change event >>>>> >>>>>> * a ConfigurationSource extends Provider> >>>>> >>>>>> * a conversion mechanism from String to T. >>>>> >>>>>> >>>>> >>>>>> we get a full fledged configuration mechanism that leverages >>>>> >>>>>> CDI. >>>>> >>>>>> >>>>> >>>>>> That would be my idea basically. WDYT? I will try to work that >>>>> >>>>>> out in >>>>> >>>>>> more details. Basically it should be implementable even with the >>>>> >>>>>> CDI >>>>> >>>>>> mechanism already in place with CDI 1.1. >>>>> >>>>>> >>>>> >>>>>> Best, >>>>> >>>>>> Anatole >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >>>>> >>>>>> >>>>> >>>>>> >: >>>>> >>>>>> One wise man* once said "EJB was a hype specification, we added >>>>> >>>>>> too >>>>> >>>>>> many things to it, it became bloated. The next hype >>>>> >>>>>> specifications are >>>>> >>>>>> JAX-RS and CDI, careful with them" >>>>> >>>>>> >>>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup >>>>> >>>>>> being >>>>> >>>>>> bloated. >>>>> >>>>>> >>>>> >>>>>> Antonio >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> *David Blevin >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand >>>>> >>>>>> > >>>>> >>>>>> wrote: >>>>> >>>>>> Hi all, >>>>> >>>>>> >>>>> >>>>>> You may have followed the rise and fall of the Java Config JSR >>>>> >>>>>> >>>>> >>>>>> (http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html). >>>>> >>>>>> Anatole in CC was leading this initiative and I proposed him to >>>>> >>>>>> join >>>>> >>>>>> us and explore if some part of his late-JSR could be done in >>>>> >>>>>> CDI. >>>>> >>>>>> >>>>> >>>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 >>>>> >>>>>> or >>>>> >>>>>> related solution. If we achieve to have a majority of specs to >>>>> >>>>>> integrate >>>>> >>>>>> with CDI, our configuration solution would therefore become a >>>>> >>>>>> configuration >>>>> >>>>>> system for all spec based on CDI 2.0. >>>>> >>>>>> >>>>> >>>>>> 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. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> Antonio Goncalves >>>>> >>>>>> Software architect, Java Champion and Pluralsight author >>>>> >>>>>> >>>>> >>>>>> Web site | >>>>> >>>>>> Twitter | >>>>> >>>>>> LinkedIn | >>>>> >>>>>> >>>>> >>>>>> Pluralsight >>>>> >>>>>> | Paris JUG | Devoxx >>>>> >>>>>> France >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> 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. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> Anatole Tresch >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead >>>>> >>>>>> Gl?rnischweg 10 >>>>> >>>>>> CH - 8620 Wetzikon >>>>> >>>>>> >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>>>> >>>>>> Twitter: @atsticks >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>>> >>>>>> Google: atsticks >>>>> >>>>>> Mobile +41-76 344 62 79 >>>>> >>>>>> -------------- next part -------------- >>>>> >>>>>> An HTML attachment was scrubbed... >>>>> >>>>>> URL: >>>>> >>>>>> >>>>> >>>>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>>>> >>>>>> *************************************** >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> 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. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> Anatole Tresch >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead >>>>> >>>>>> Gl?rnischweg 10 >>>>> >>>>>> CH - 8620 Wetzikon >>>>> >>>>>> >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>>>> >>>>>> Twitter: @atsticks >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>>> >>>>>> Google: atsticks >>>>> >>>>>> Mobile +41-76 344 62 79 >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> 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. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Anatole Tresch >>>>> >>>>> Java Lead Engineer, JSR Spec Lead >>>>> >>>>> Gl?rnischweg 10 >>>>> >>>>> CH - 8620 Wetzikon >>>>> >>>>> >>>>> >>>>> Switzerland, Europe Zurich, GMT+1 >>>>> >>>>> Twitter: @atsticks >>>>> >>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>>> >>>>> Google: atsticks >>>>> >>>>> Mobile +41-76 344 62 79 >>>>> >>>> >>>>> >>>> >>>>> >>> >>>>> >> >>>>> >> >>>>> >> >>>>> >> -- >>>>> >> Anatole Tresch >>>>> >> Java Lead Engineer, JSR Spec Lead >>>>> >> Gl?rnischweg 10 >>>>> >> CH - 8620 Wetzikon >>>>> >> >>>>> >> Switzerland, Europe Zurich, GMT+1 >>>>> >> Twitter: @atsticks >>>>> >> Blogs: http://javaremarkables.blogspot.ch/ >>>>> >> Google: atsticks >>>>> >> Mobile +41-76 344 62 79 >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > 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. >>>> >>>> >>>> >>>> >>>> -- >>>> Anatole Tresch >>>> Java Lead Engineer, JSR Spec Lead >>>> Gl?rnischweg 10 >>>> CH - 8620 Wetzikon >>>> >>>> Switzerland, Europe Zurich, GMT+1 >>>> Twitter: @atsticks >>>> Blogs: http://javaremarkables.blogspot.ch/ >>>> Google: atsticks >>>> Mobile +41-76 344 62 79 >>> >>> >>> _______________________________________________ >>> 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. >> >> >> >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France From issues at jboss.org Mon Sep 8 05:54:00 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 8 Sep 2014 05:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999793#comment-12999793 ] Romain Manni-Bucau commented on CDI-456: ---------------------------------------- I think main issue today regarding it is the javadoc doesn't state what you get when. So basically you don't know what you get. IMHO this thing should be well defined and not rely on a "hack" getBeanClass still makes sense for proxying IMHO > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antoine at sabot-durand.net Mon Sep 8 06:03:36 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 8 Sep 2014 12:03:36 +0200 Subject: [cdi-dev] Enhancement proposition to JSR 330 Message-ID: Hi all, I received an answer from Bob Lee (off list). He likes te idea of us providing a proposal document. So I worked on it this WE. Here it is : https://docs.google.com/document/d/1KCzqodA8uzXED5DJrEUyl0x3dOUB5mBwL4KcV8xUY_w/edit?usp=sharing Your comments and proposal are most welcome. I propose we discuss this point during our next meeting, and if we agree on the final content send it asap to have Bob and Juergen feeling about these suggestion. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/607a6499/attachment.html From werner.keil at gmail.com Mon Sep 8 06:06:30 2014 From: werner.keil at gmail.com (Werner Keil) Date: Mon, 8 Sep 2014 12:06:30 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: As a side note, if the BV Spec is now Apache, those who want to write "their own flavor" of Spec and API can do so in these cases;-) Which is also why Anatole (and other EC Members talking to Oracle Legal, etc.) said, Oracle "tolerates" the Apache Licensing of even the Spec Document, but it is a two-headed sword for compatibility. A vendor taking that spec and adding their own "appendix" would not be sued (like for other parts of the Java ecosystem;-p) but it may end up as a proprietary feature to that container alone. If let's say a simple desktop app has no need for an extensible "stage" concept and API, then that's a perfect example where optionality just like under MEEP 8 makes sense in the SE/EE world, too. Not because of size, but choice and keeping the burden for developers (and implementors, if they don't want to use it) lower than e.g. with SE 8 and 5 different (mandatory) Date/Time APIs;-| Werner On Mon, Sep 8, 2014 at 11:51 AM, Romain Manni-Bucau wrote: > @Antonio: -1 for an appendix, bean validation is the example it is > broken. Idea is awesome, everybody liked it so it was added -> great. > Here everybody already agrees it is good so no need of "staging" phase > IMHO. BV appendix was not the API used so it broke apps using it. SO > using proprietary stuff is the same, it basically mean an appendix > spec for something not under discussion (regarding its need) is IMHO > useless. > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > 2014-09-08 10:29 GMT+02:00 Werner Keil : > > Hi, > > > > If it's not really usable as API or annotation I don't see much value in > > adding some "how to" or intent for the future into the Spec Document. > > > > If it was to become a part of CDI 2, there's nothing against optionality > > like MEEP 8 or JSR 363 already practice on the SE/EE side either. > > > > Agorava/DeltaSpike demonstrate how true modularity work, similar to the > JSRs > > mentioned above, where you have multiple module JARs/bundles instead of a > > big monolithic one. Some JSRs like Batch also declared separate > "annotation" > > modules, so that's what CDI 2 should also do if it was a feature Inside > of > > it. > > Calling some features optional if they're not used by every > implementation > > allows them to chose. That was also the main value of keeping @Inject a > > separate "module" under CDI. It was never included into a JDK but used > > independently. > > > > The core of a Config module would ideally work in SE, but CDI 2 already > > declared an aim to have some modules work under SE. > > > > Werner > > > > Am 08.09.2014 09:47 schrieb "Antonio Goncalves" > > : > > > >> Hi all, > >> > >> I really have some concerns about adding configuration into CDI but I > can > >> see benefits too. And what about adding it... and not adding it at the > same > >> time ? In Bean Validation 1.0, the Expert Group decided not to include > >> method-level validation in the spec (it was included in 1.1). But what > they > >> did is to add it as a proposal in the Appendix. > >> > >> If we feel some configuration should get in, why not have a proposal in > >> the Appendix of CDI 2.0 ? It could then be implemented by Weld (and > >> OpenWebBeans if they feel like it). And then, if it's successful and > things > >> get easier, get its own JSR for Java EE 9. > >> > >> WDYT ? > >> > >> Antonio > >> > >> On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau < > rmannibucau at gmail.com> > >> wrote: > >>> > >>> Hmm > >>> > >>> I see config jsr as a jse spec which would allow EE injections in > config > >>> components in EE containers (exactly like jbatch). > >>> > >>> This way it can be used without any container or with any container > >>> easily. Only limit will be to not do something cdi/known containers > will not > >>> support I think. > >>> > >>> Not sure EE side is needed today, a lot can already be done without it > >>> and it can be enhanced later adding some integration words. > >>> > >>> Le 8 sept. 2014 00:01, "Anatole Tresch" a ?crit : > >>> > >>>> Hi Romain > >>>> > >>>> just a few remarks inline... > >>>> > >>>> Summarizing > >>>> 1) injection of values, reinjection, feedback on config changes can > all > >>>> be done with already existing features (producers, extensions). > >>>> 2) configuring/bootstrapping CDI itself, e.g. configuration, is > targeted > >>>> with CDI 2.0 (see spec failing) > >>>> > >>>> So basically we could try to look if there is enough interest to > >>>> standardize configuration in a more general way. For deployment > aspects we > >>>> need an EE JSR, for the rest, another SE standard may be an option as > >>>> well... tbd... > >>>> > >>>> -Anatole > >>>> > >>>> > >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : > >>>>> > >>>>> well sorry to pop in so late but here are my 2cts > >>>> > >>>> easy ;) > >>>> > >>>>> > >>>>> Config JSR is more about environment config IMHO and putting it in > CDI > >>>>> doesn't make sense since more or more spec works without any other > >>>>> spec - CDI in our case. > >>>> > >>>> CDI even with some config mechanism added would still work > "standalone". > >>>> > >>>> > >>>>> > >>>>> This mean CDI can't be the place but should > >>>>> just be the bridge for config JSR. > >>>> > >>>> As I suggested as well. > >>>> > >>>> > >>>>> > >>>>> Plus CDI config will surely highly > >>>>> be an application config first (beans.xml should be the place then) > >>>> > >>>> Yes, app config, but beware people of writing config into beans.xml. > >>>> That is definitively in most cases not what you want. CDI should not > define, > >>>> where and how config is located and formatted. CDI should provide a > SPI, > >>>> where config providers can publish the configured values, so it can be > >>>> injected wherever needed. E.g. some kind of producer, that can provide > >>>> multiple objects to be injected and can benefit from some kind of > callback > >>>> mechanism would be sufficient... > >>>> > >>>>> > >>>>> then environment config can be done at EE level (saying it has to > >>>>> support placeholders or any pre deployment processing). > >>>> > >>>> Config is much more complex. There is no clear border what is > >>>> environment config or environment dependent and what not. This > depends on > >>>> what kind of application you have deployed. As an example the email > address, > >>>> where you send error messages, can be different depenending on the > >>>> stage/environment, but this is not EE related config entry. Also what > an > >>>> environment is, is not a thing that you can define completely. So I > agree > >>>> not to add this complexities to CDI, I would hide them between some > kind of > >>>> "config provider", as mentioned above. CDI does not need to know if > the > >>>> config provided is environment dependent or not, its just what is > visible at > >>>> a current runtime state... > >>>> > >>>>> > >>>>> If you put something like ProjectStage in CDI it is great but then > you > >>>>> have it in JSF, CDI and finally surely all specs...same as > >>>>> converters... > >>>> > >>>> That was originally the idea, when doing a EE config JSR, but without > >>>> such standard. I agree, CDI is not the place to define them. > >>>> > >>>> > >>>>> > >>>>> Config should really be split in: > >>>>> 1) spec dependent config -> spec.xml > >>>>> 2) *common* config (a bit like javax.annotation) for environment and > >>>>> external configuration -> Config JSR > >>>> > >>>> Not 100% sure, if a get the point here... > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : > >>>>> > >>>>> well sorry to pop in so late but here are my 2cts > >>>>> > >>>>> Config JSR is more about environment config IMHO and putting it in > CDI > >>>>> doesn't make sense since more or more spec works without any other > >>>>> spec - CDI in our case. This mean CDI can't be the place but should > >>>>> just be the bridge for config JSR. Plus CDI config will surely highly > >>>>> be an application config first (beans.xml should be the place then) > >>>>> then environment config can be done at EE level (saying it has to > >>>>> support placeholders or any pre deployment processing). > >>>>> > >>>>> If you put something like ProjectStage in CDI it is great but then > you > >>>>> have it in JSF, CDI and finally surely all specs...same as > >>>>> converters... > >>>>> > >>>>> Config should really be split in: > >>>>> 1) spec dependent config -> spec.xml > >>>>> 2) *common* config (a bit like javax.annotation) for environment and > >>>>> external configuration -> Config JSR > >>>>> > >>>>> wdyt? > >>>>> > >>>>> > >>>>> > >>>>> Romain Manni-Bucau > >>>>> Twitter: @rmannibucau > >>>>> Blog: http://rmannibucau.wordpress.com/ > >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau > >>>>> Github: https://github.com/rmannibucau > >>>>> > >>>>> > >>>>> 2014-09-07 23:39 GMT+02:00 Werner Keil : > >>>>> > Sounds like an argument for a CDI module rather than a separate JSR > >>>>> > then?;-) > >>>>> > > >>>>> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch < > atsticks at gmail.com> > >>>>> > wrote: > >>>>> >> > >>>>> >> I would not worry about CDI regarding licensing. Just the sentence > >>>>> >> was > >>>>> >> that Oracle does not want to have more ALv2 in addition to what is > >>>>> >> already > >>>>> >> there. So as long as we do things within CDI, no worries, I think. > >>>>> >> For new > >>>>> >> EE JSRs nevertheless this is a BIG issue and should be clarified > by > >>>>> >> the EC! > >>>>> >> > >>>>> >> > >>>>> >> 2014-09-07 21:44 GMT+02:00 Werner Keil : > >>>>> >>> > >>>>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec > under > >>>>> >>> ALv2 > >>>>> >>> as a dual-license, this was discussed by EC Members but both JCP > EC > >>>>> >>> and > >>>>> >>> Oracle Legal/PMO seems fine with it, and CDI is already an > >>>>> >>> essential > >>>>> >>> building block to Java EE 6/7, hence used with Glassfish, too. I > >>>>> >>> wasn't > >>>>> >>> involved in these discussions, but given CDI is especially > liberal > >>>>> >>> and fully > >>>>> >>> accepted by JCP formalities and license policies, I don't really > >>>>> >>> see what > >>>>> >>> the problem wss for Anatole's JSR attempt (though I know, both > >>>>> >>> Oracle and > >>>>> >>> other EC Members/companies don't always prefer this kind of > >>>>> >>> licensing...;-) > >>>>> >>> > >>>>> >>> Werner > >>>>> >>> > >>>>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament > >>>>> >>> > >>>>> >>> wrote: > >>>>> >>>> > >>>>> >>>> Ok, this mail has me more concerned than anything. Can you > >>>>> >>>> clarify this > >>>>> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. > >>>>> >>>> > >>>>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch > >>>>> >>>> > >>>>> >>>> wrote: > >>>>> >>>>> > >>>>> >>>>> Hi All > >>>>> >>>>> > >>>>> >>>>> unfortunately things seem quite complicated: > >>>>> >>>>> > >>>>> >>>>> first of all, similarities with Deltaspike are basically not > >>>>> >>>>> accidental. The concepts we developed in Credit Suisse are very > >>>>> >>>>> similar to > >>>>> >>>>> Deltaspike, though Deltaspike was not yet born at that time. > >>>>> >>>>> Fortunately we > >>>>> >>>>> ended up with a similar kind of solution. > >>>>> >>>>> filtering still can be done. My idea is to define some kind of > >>>>> >>>>> "configuration provider", which then is dynamically asked for > >>>>> >>>>> configuration. > >>>>> >>>>> How the provider is internally organized, is completely > >>>>> >>>>> transparent to CDI. > >>>>> >>>>> This enables to have multi-layered, complex config solutions > work > >>>>> >>>>> the same > >>>>> >>>>> (from a view point of CDI) like simple programmatic test > >>>>> >>>>> configurations > >>>>> >>>>> during unit tests. The config provider still can support > >>>>> >>>>> filtering and > >>>>> >>>>> dynamic resolution as commonly used in configuration systems. > >>>>> >>>>> Similarly the > >>>>> >>>>> format is basically also not fixed. Of course, would a > reference > >>>>> >>>>> implementation provide a set of functionalities, but I would > >>>>> >>>>> definitively > >>>>> >>>>> not define the exact configuration mechanism as part of the CDI > >>>>> >>>>> (or even a > >>>>> >>>>> EE config JSR). Another reason, beside complexity and time, is > >>>>> >>>>> the fact that > >>>>> >>>>> different companies handle, store and manage configuration > >>>>> >>>>> differently, so a > >>>>> >>>>> mechanism must be flexible enough to accommodate these, without > >>>>> >>>>> adoption > >>>>> >>>>> rate will be low. Furthermore this flexibility also keeps doors > >>>>> >>>>> open for use > >>>>> >>>>> cases we do not know yet. > >>>>> >>>>> Also we have to separate some basically two types of > >>>>> >>>>> configuration > >>>>> >>>>> aspects: > >>>>> >>>>> > >>>>> >>>>> application config basically is injected into deployed > >>>>> >>>>> components, but > >>>>> >>>>> basically only can affect deployment to the extend it can be > >>>>> >>>>> managed and > >>>>> >>>>> injected by CDI. The basic architecture and design, how > >>>>> >>>>> application servers > >>>>> >>>>> to load and deploy are basically not affected. This type of > >>>>> >>>>> configuration > >>>>> >>>>> (mechanism) I see also as a possible addition to CDI, if we > >>>>> >>>>> really fail to > >>>>> >>>>> do something in another JSR. With CDI going for a more modular > >>>>> >>>>> design, even > >>>>> >>>>> basic configuration of CDI can be possible, given we have some > >>>>> >>>>> kind of API, > >>>>> >>>>> we can access during CDI initialization. > >>>>> >>>>> On the other side deployment configuration affects directly how > >>>>> >>>>> the > >>>>> >>>>> application server deploys the application. Configuration here > >>>>> >>>>> would allow > >>>>> >>>>> to define datasources, EJBs, transactional aspects, security, > >>>>> >>>>> persistence, > >>>>> >>>>> war and ear configurations etc. Basically everything you do as > of > >>>>> >>>>> today with > >>>>> >>>>> some kind of XML file, or annotation. Hereby enabling more > >>>>> >>>>> flexibility into > >>>>> >>>>> the existing descriptors is relatively easy, but as mentioned > by > >>>>> >>>>> Mark, > >>>>> >>>>> constraint. Adding more flexibility raises other subtle > problems. > >>>>> >>>>> Imagine a > >>>>> >>>>> application module, e.g. a war, that defines everything it > >>>>> >>>>> requires. There > >>>>> >>>>> is no need to configure anything more on server side (with > spring > >>>>> >>>>> you can do > >>>>> >>>>> this, with Java EE unfortunately not). But this has a severe > >>>>> >>>>> consequence, it > >>>>> >>>>> would make the application really portable in the sense, that > it > >>>>> >>>>> can be > >>>>> >>>>> moved between different app servers (vendors) without any > change > >>>>> >>>>> (ideally). > >>>>> >>>>> As a result commercial profits of some vendor companies may be > >>>>> >>>>> affected. I > >>>>> >>>>> think this is actually one of the key points, why things are > >>>>> >>>>> getting so > >>>>> >>>>> complicated in that area. > >>>>> >>>>> > >>>>> >>>>> Legal aspects also were discussed. One of them is a possible > >>>>> >>>>> legal > >>>>> >>>>> clash of ALv2 with GPL. This is the case already within > >>>>> >>>>> Glassfish, but one > >>>>> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal > >>>>> >>>>> department. At > >>>>> >>>>> the end we decided to use a BSD model. Even dual licensing > >>>>> >>>>> BSD/ALv2 could > >>>>> >>>>> theoretically be an option. If you would choose ALv2, Oracle > will > >>>>> >>>>> not > >>>>> >>>>> include your RI into Glassfish, which is the RI for the EE > >>>>> >>>>> Umbrella JSR, > >>>>> >>>>> meaning your JSR will not be included into EE8. So what should > we > >>>>> >>>>> do? I > >>>>> >>>>> don't have a good answer... > >>>>> >>>>> > >>>>> >>>>> So, I like to discuss configuration aspects here. Nevertheless > if > >>>>> >>>>> we > >>>>> >>>>> decide to add config aspects, be aware that we might only > >>>>> >>>>> (mainly) support > >>>>> >>>>> application config, since everything else directly would impact > >>>>> >>>>> other JSRs. > >>>>> >>>>> And that is obviously quite similar to what Apache Deltaspike > is > >>>>> >>>>> all about > >>>>> >>>>> ;-) > >>>>> >>>>> > >>>>> >>>>> Cheers, > >>>>> >>>>> Anatole > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : > >>>>> >>>>>> > >>>>> >>>>>> Yes, the config group also was (obviously) looking at > >>>>> >>>>>> DeltaSpikes > >>>>> >>>>>> config mechanism as well. > >>>>> >>>>>> There were others who wanted to go more into the 'filtering' > >>>>> >>>>>> approach > >>>>> >>>>>> as done on WebLogic servers (though not sure who else does > that > >>>>> >>>>>> as well). > >>>>> >>>>>> You know, having all the XML configs like WEB-INF/web.xml > >>>>> >>>>>> containing > >>>>> >>>>>> placeholders and the real values only get placed in there at > >>>>> >>>>>> deployment > >>>>> >>>>>> time. I personally find this approach a bit limited from a > >>>>> >>>>>> technical > >>>>> >>>>>> perspective and it already didn't work out for me when using > >>>>> >>>>>> WebLogic (what > >>>>> >>>>>> about changing a configured value after the deployment was > done? > >>>>> >>>>>> What about > >>>>> >>>>>> security? Having passwords in web.xml, unit testing, ...). > >>>>> >>>>>> There are of course also other approaches which all might have > >>>>> >>>>>> strong > >>>>> >>>>>> sides and would have needed to get discussed. > >>>>> >>>>>> > >>>>> >>>>>> But utterly the problem seems to have been legal reasons. We > >>>>> >>>>>> even > >>>>> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF > >>>>> >>>>>> project with > >>>>> >>>>>> substantial support and participation from the JBoss, > DeltaSpike > >>>>> >>>>>> and TomEE > >>>>> >>>>>> communities. > >>>>> >>>>>> > >>>>> >>>>>> Anyway, the time will come when we will resurrect this effort. > >>>>> >>>>>> > >>>>> >>>>>> LieGrue, > >>>>> >>>>>> strub > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> Yep, it contains a simple but extendable notion of > ProjectStage, > >>>>> >>>>>> too;-) > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament > >>>>> >>>>>> > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> Anatole, > >>>>> >>>>>> > >>>>> >>>>>> I'm wondering if some of your configuration description falls > >>>>> >>>>>> under > >>>>> >>>>>> what was put together in DeltaSpike? > >>>>> >>>>>> > >>>>> >>>>>> http://deltaspike.apache.org/configuration.html > >>>>> >>>>>> > >>>>> >>>>>> John > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch > >>>>> >>>>>> > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> Staging is not a question of xml or not xml (the "format" of > >>>>> >>>>>> config). > >>>>> >>>>>> You can do staged config also using xml, or based on a > database > >>>>> >>>>>> or json > >>>>> >>>>>> config service. Staging as well as, more generally speaking, > >>>>> >>>>>> environment > >>>>> >>>>>> dependent config is more like to select/filter the right > config > >>>>> >>>>>> that targets > >>>>> >>>>>> the current (runtime) environment. This might include stages, > >>>>> >>>>>> but also many > >>>>> >>>>>> other aspects are feasible and common (server, tier, ear, war, > >>>>> >>>>>> tenant ...). > >>>>> >>>>>> Since these aspects are per se very complex, it might be > >>>>> >>>>>> advisable to leave > >>>>> >>>>>> them out of any spec (even a dedicated config JSR would > probably > >>>>> >>>>>> not be > >>>>> >>>>>> capable of covering these within the relatively short EE > >>>>> >>>>>> timeframe)... > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil >: > >>>>> >>>>>> > >>>>> >>>>>> Jens/all, > >>>>> >>>>>> > >>>>> >>>>>> A sort of "staging" already was possible using CDI earlier, > see > >>>>> >>>>>> examples like this: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war > >>>>> >>>>>> > >>>>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond > the > >>>>> >>>>>> primitive, hard-coded JSF enum. > >>>>> >>>>>> > >>>>> >>>>>> If that works without XML, while still allowing flexible > >>>>> >>>>>> configuration > >>>>> >>>>>> for different stages or to add and "inject" additional stages > >>>>> >>>>>> maybe even on > >>>>> >>>>>> a tenant basis (for Cloud scenarios) I could see something > like > >>>>> >>>>>> that work > >>>>> >>>>>> without XML. In the Multiconf project we managed to code > >>>>> >>>>>> everything in > >>>>> >>>>>> Python, and similar to Puppet or Chef you can configure and > >>>>> >>>>>> deploy multiple > >>>>> >>>>>> environments with it, Java EE, Spring or Play! several of them > >>>>> >>>>>> are > >>>>> >>>>>> configured this way and it requires no XML (where the > container > >>>>> >>>>>> needs such > >>>>> >>>>>> files, the framework generates them;-) > >>>>> >>>>>> > >>>>> >>>>>> Werner > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, > >>>>> >>>>>> > >>>>> >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole > >>>>> >>>>>> Tresch) > >>>>> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) > >>>>> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() > definition > >>>>> >>>>>> (Anatole Tresch (JIRA)) > >>>>> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) > >>>>> >>>>>> > >>>>> >>>>>> ------------------------------ > >>>>> >>>>>> > >>>>> >>>>>> Message: 4 > >>>>> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 > >>>>> >>>>>> From: Jens Schumann > >>>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... > >>>>> >>>>>> To: Anatole Tresch , Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> Cc: cdi-dev > >>>>> >>>>>> Message-ID: > >>>>> >>>>>> Content-Type: text/plain; charset="windows-1252" > >>>>> >>>>>> > >>>>> >>>>>> I can confirm that this approach works very well. We are > using a > >>>>> >>>>>> similar approach a couple of years now, and I love the > >>>>> >>>>>> simplicity that comes > >>>>> >>>>>> with portable extensions and @Producer methods. See our public > >>>>> >>>>>> version here > >>>>> >>>>>> [1] (works since early CDI 1.0 days) . > >>>>> >>>>>> > >>>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier > >>>>> >>>>>> @Property. > >>>>> >>>>>> We support default values and type conversation for primitives > >>>>> >>>>>> and > >>>>> >>>>>> everything that has a string based constructor. The property > >>>>> >>>>>> source can be > >>>>> >>>>>> anything, from property files (default) to databases or xml > >>>>> >>>>>> files. For > >>>>> >>>>>> examples see tests here [2]. > >>>>> >>>>>> > >>>>> >>>>>> Nevertheless I am not sure if this should be part of an future > >>>>> >>>>>> CDI > >>>>> >>>>>> spec. My concerns include the bloat argument, of course. But > the > >>>>> >>>>>> main reason > >>>>> >>>>>> relates to the fact that we have almost everything in the > >>>>> >>>>>> current CDI spec > >>>>> >>>>>> already. > >>>>> >>>>>> > >>>>> >>>>>> Right now I am quite happy with an custom portable extension > >>>>> >>>>>> that does > >>>>> >>>>>> everything for me. At the time we implemented the extension we > >>>>> >>>>>> realised that > >>>>> >>>>>> the "hard part" was writing an extension that links a > qualified > >>>>> >>>>>> "optional > >>>>> >>>>>> injection point" with an @Producer method while supporting > code > >>>>> >>>>>> based > >>>>> >>>>>> default values. Luckily I had Arne in my team who did that > >>>>> >>>>>> within a few > >>>>> >>>>>> minutes. > >>>>> >>>>>> > >>>>> >>>>>> Because of this experience I would propose that we simplify > >>>>> >>>>>> extension > >>>>> >>>>>> development such that "optional injection points" may be > linked > >>>>> >>>>>> to @Produces > >>>>> >>>>>> values easily. Additionally we have to solve a few more > >>>>> >>>>>> integration issues > >>>>> >>>>>> (e.g. read-only DB access should be available during CDI > >>>>> >>>>>> startup). > >>>>> >>>>>> Everything else should be provided by portable extensions > (e.g. > >>>>> >>>>>> via > >>>>> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. > >>>>> >>>>>> > >>>>> >>>>>> Jens > >>>>> >>>>>> [1] > >>>>> >>>>>> > >>>>> >>>>>> > https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property > >>>>> >>>>>> [2] > >>>>> >>>>>> > >>>>> >>>>>> > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property > >>>>> >>>>>> > >>>>> >>>>>> Von: Anatole Tresch > >>>>> >>>>>> > > >>>>> >>>>>> Datum: Friday 5 September 2014 21:22 > >>>>> >>>>>> An: Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> antonio.goncalves at gmail.com>> > >>>>> >>>>>> Cc: CDI-Dev > >>>>> >>>>>> > > >>>>> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... > >>>>> >>>>>> > >>>>> >>>>>> Hi all, > >>>>> >>>>>> > >>>>> >>>>>> I would not like to add an XML "bloated" mechanism as part of > >>>>> >>>>>> CDI 2.0. > >>>>> >>>>>> Spontaneously I would propose a more CDI like things like: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> * Adding a @Configured annotation (basically a qualifier). > >>>>> >>>>>> This > >>>>> >>>>>> can be in addition to @Inject and would allow to inject > >>>>> >>>>>> "configured" values. > >>>>> >>>>>> * Since configuration can change we may think of a (CDI) > >>>>> >>>>>> event/reinject mechanism based on config changes. By default, > >>>>> >>>>>> this is > >>>>> >>>>>> switched off and we can discuss how it would be activated, > e.g. > >>>>> >>>>>> by an > >>>>> >>>>>> additional flag settable with the @Configured annotation, or > an > >>>>> >>>>>> additional > >>>>> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon > >>>>> >>>>>> framework), or both. > >>>>> >>>>>> * Hereby configured values theoretically behave similar as > >>>>> >>>>>> all > >>>>> >>>>>> other injection points. They also can be qualified (the aspect > >>>>> >>>>>> of scopes, I > >>>>> >>>>>> did not yet have time to think about). The only difference is, > >>>>> >>>>>> that they are > >>>>> >>>>>> satisified using the configuration "system". > >>>>> >>>>>> * The configuration "source" itself could in the extreme > >>>>> >>>>>> simplest > >>>>> >>>>>> way be a Provider>. The CDI spec should not > >>>>> >>>>>> care about > >>>>> >>>>>> how this map is provided (XML, DB, overrides, etc). This still > >>>>> >>>>>> can be > >>>>> >>>>>> standardized later. As long as the ConfigurationSource SPI is > >>>>> >>>>>> defined, > >>>>> >>>>>> companies still can hook in the logic and level of > configuration > >>>>> >>>>>> abstraction > >>>>> >>>>>> they need. > >>>>> >>>>>> * Of course, since not only Strings can be injected, we > need > >>>>> >>>>>> some > >>>>> >>>>>> conversion or adapter logic as basically outlined in my blog. > >>>>> >>>>>> Also here we > >>>>> >>>>>> can add a simple SPI and let the details to the RI. > >>>>> >>>>>> > >>>>> >>>>>> Summarizing a > >>>>> >>>>>> > >>>>> >>>>>> * @Configured annotation > >>>>> >>>>>> * some kind of change event > >>>>> >>>>>> * a ConfigurationSource extends > Provider> > >>>>> >>>>>> * a conversion mechanism from String to T. > >>>>> >>>>>> > >>>>> >>>>>> we get a full fledged configuration mechanism that leverages > >>>>> >>>>>> CDI. > >>>>> >>>>>> > >>>>> >>>>>> That would be my idea basically. WDYT? I will try to work that > >>>>> >>>>>> out in > >>>>> >>>>>> more details. Basically it should be implementable even with > the > >>>>> >>>>>> CDI > >>>>> >>>>>> mechanism already in place with CDI 1.1. > >>>>> >>>>>> > >>>>> >>>>>> Best, > >>>>> >>>>>> Anatole > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> antonio.goncalves at gmail.com>>: > >>>>> >>>>>> One wise man* once said "EJB was a hype specification, we > added > >>>>> >>>>>> too > >>>>> >>>>>> many things to it, it became bloated. The next hype > >>>>> >>>>>> specifications are > >>>>> >>>>>> JAX-RS and CDI, careful with them" > >>>>> >>>>>> > >>>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup > >>>>> >>>>>> being > >>>>> >>>>>> bloated. > >>>>> >>>>>> > >>>>> >>>>>> Antonio > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> *David Blevin > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand > >>>>> >>>>>> > > >>>>> >>>>>> wrote: > >>>>> >>>>>> Hi all, > >>>>> >>>>>> > >>>>> >>>>>> You may have followed the rise and fall of the Java Config JSR > >>>>> >>>>>> > >>>>> >>>>>> ( > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > ). > >>>>> >>>>>> Anatole in CC was leading this initiative and I proposed him > to > >>>>> >>>>>> join > >>>>> >>>>>> us and explore if some part of his late-JSR could be done in > >>>>> >>>>>> CDI. > >>>>> >>>>>> > >>>>> >>>>>> I?m mainly thinking of > https://issues.jboss.org/browse/CDI-123 > >>>>> >>>>>> or > >>>>> >>>>>> related solution. If we achieve to have a majority of specs to > >>>>> >>>>>> integrate > >>>>> >>>>>> with CDI, our configuration solution would therefore become a > >>>>> >>>>>> configuration > >>>>> >>>>>> system for all spec based on CDI 2.0. > >>>>> >>>>>> > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Antonio Goncalves > >>>>> >>>>>> Software architect, Java Champion and Pluralsight author > >>>>> >>>>>> > >>>>> >>>>>> Web site | > >>>>> >>>>>> Twitter | > >>>>> >>>>>> LinkedIn | > >>>>> >>>>>> > >>>>> >>>>>> Pluralsight< > http://pluralsight.com/training/Authors/Details/antonio-goncalves> > >>>>> >>>>>> | Paris JUG | Devoxx > >>>>> >>>>>> France > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Anatole Tresch > >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>>> Gl?rnischweg 10 > >>>>> >>>>>> CH - 8620 Wetzikon > >>>>> >>>>>> > >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>>> Twitter: @atsticks > >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>>> Google: atsticks > >>>>> >>>>>> Mobile +41-76 344 62 79 > >>>>> >>>>>> -------------- next part -------------- > >>>>> >>>>>> An HTML attachment was scrubbed... > >>>>> >>>>>> URL: > >>>>> >>>>>> > >>>>> >>>>>> > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 > >>>>> >>>>>> *************************************** > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Anatole Tresch > >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>>> Gl?rnischweg 10 > >>>>> >>>>>> CH - 8620 Wetzikon > >>>>> >>>>>> > >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>>> Twitter: @atsticks > >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>>> Google: atsticks > >>>>> >>>>>> Mobile +41-76 344 62 79 > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> -- > >>>>> >>>>> Anatole Tresch > >>>>> >>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>> Gl?rnischweg 10 > >>>>> >>>>> CH - 8620 Wetzikon > >>>>> >>>>> > >>>>> >>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>> Twitter: @atsticks > >>>>> >>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>> Google: atsticks > >>>>> >>>>> Mobile +41-76 344 62 79 > >>>>> >>>> > >>>>> >>>> > >>>>> >>> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> -- > >>>>> >> Anatole Tresch > >>>>> >> Java Lead Engineer, JSR Spec Lead > >>>>> >> Gl?rnischweg 10 > >>>>> >> CH - 8620 Wetzikon > >>>>> >> > >>>>> >> Switzerland, Europe Zurich, GMT+1 > >>>>> >> Twitter: @atsticks > >>>>> >> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >> Google: atsticks > >>>>> >> Mobile +41-76 344 62 79 > >>>>> > > >>>>> > > >>>>> > > >>>>> > _______________________________________________ > >>>>> > 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. > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Anatole Tresch > >>>> Java Lead Engineer, JSR Spec Lead > >>>> Gl?rnischweg 10 > >>>> CH - 8620 Wetzikon > >>>> > >>>> Switzerland, Europe Zurich, GMT+1 > >>>> Twitter: @atsticks > >>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>> Google: atsticks > >>>> Mobile +41-76 344 62 79 > >>> > >>> > >>> _______________________________________________ > >>> 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. > >> > >> > >> > >> > >> -- > >> Antonio Goncalves > >> Software architect, Java Champion and Pluralsight author > >> > >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/ee8f7586/attachment-0001.html From pmuir at redhat.com Mon Sep 8 06:11:34 2014 From: pmuir at redhat.com (Pete Muir) Date: Mon, 8 Sep 2014 11:11:34 +0100 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: On 8 Sep 2014, at 11:06, Werner Keil wrote: > As a side note, if the BV Spec is now Apache, those who want to write "their own flavor" of Spec and API can do so in these cases;-) > Which is also why Anatole (and other EC Members talking to Oracle Legal, etc.) said, Oracle "tolerates" the Apache Licensing of even the Spec Document, but it is a two-headed sword for compatibility. > > A vendor taking that spec and adding their own "appendix" would not be sued (like for other parts of the Java ecosystem;-p) but it may end up as a proprietary feature to that container alone. Right, but at this point they are no longer implementing ?CDI?, they are now implementing ?vendors-variation-of-CDI?... > > If let's say a simple desktop app has no need for an extensible "stage" concept and API, then that's a perfect example where optionality just like under MEEP 8 makes sense in the SE/EE world, too. Not because of size, but choice and keeping the burden for developers (and implementors, if they don't want to use it) lower than e.g. with SE 8 and 5 different (mandatory) Date/Time APIs;-| > > Werner > > On Mon, Sep 8, 2014 at 11:51 AM, Romain Manni-Bucau wrote: > @Antonio: -1 for an appendix, bean validation is the example it is > broken. Idea is awesome, everybody liked it so it was added -> great. > Here everybody already agrees it is good so no need of "staging" phase > IMHO. BV appendix was not the API used so it broke apps using it. SO > using proprietary stuff is the same, it basically mean an appendix > spec for something not under discussion (regarding its need) is IMHO > useless. > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > 2014-09-08 10:29 GMT+02:00 Werner Keil : > > Hi, > > > > If it's not really usable as API or annotation I don't see much value in > > adding some "how to" or intent for the future into the Spec Document. > > > > If it was to become a part of CDI 2, there's nothing against optionality > > like MEEP 8 or JSR 363 already practice on the SE/EE side either. > > > > Agorava/DeltaSpike demonstrate how true modularity work, similar to the JSRs > > mentioned above, where you have multiple module JARs/bundles instead of a > > big monolithic one. Some JSRs like Batch also declared separate "annotation" > > modules, so that's what CDI 2 should also do if it was a feature Inside of > > it. > > Calling some features optional if they're not used by every implementation > > allows them to chose. That was also the main value of keeping @Inject a > > separate "module" under CDI. It was never included into a JDK but used > > independently. > > > > The core of a Config module would ideally work in SE, but CDI 2 already > > declared an aim to have some modules work under SE. > > > > Werner > > > > Am 08.09.2014 09:47 schrieb "Antonio Goncalves" > > : > > > >> Hi all, > >> > >> I really have some concerns about adding configuration into CDI but I can > >> see benefits too. And what about adding it... and not adding it at the same > >> time ? In Bean Validation 1.0, the Expert Group decided not to include > >> method-level validation in the spec (it was included in 1.1). But what they > >> did is to add it as a proposal in the Appendix. > >> > >> If we feel some configuration should get in, why not have a proposal in > >> the Appendix of CDI 2.0 ? It could then be implemented by Weld (and > >> OpenWebBeans if they feel like it). And then, if it's successful and things > >> get easier, get its own JSR for Java EE 9. > >> > >> WDYT ? > >> > >> Antonio > >> > >> On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau > >> wrote: > >>> > >>> Hmm > >>> > >>> I see config jsr as a jse spec which would allow EE injections in config > >>> components in EE containers (exactly like jbatch). > >>> > >>> This way it can be used without any container or with any container > >>> easily. Only limit will be to not do something cdi/known containers will not > >>> support I think. > >>> > >>> Not sure EE side is needed today, a lot can already be done without it > >>> and it can be enhanced later adding some integration words. > >>> > >>> Le 8 sept. 2014 00:01, "Anatole Tresch" a ?crit : > >>> > >>>> Hi Romain > >>>> > >>>> just a few remarks inline... > >>>> > >>>> Summarizing > >>>> 1) injection of values, reinjection, feedback on config changes can all > >>>> be done with already existing features (producers, extensions). > >>>> 2) configuring/bootstrapping CDI itself, e.g. configuration, is targeted > >>>> with CDI 2.0 (see spec failing) > >>>> > >>>> So basically we could try to look if there is enough interest to > >>>> standardize configuration in a more general way. For deployment aspects we > >>>> need an EE JSR, for the rest, another SE standard may be an option as > >>>> well... tbd... > >>>> > >>>> -Anatole > >>>> > >>>> > >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : > >>>>> > >>>>> well sorry to pop in so late but here are my 2cts > >>>> > >>>> easy ;) > >>>> > >>>>> > >>>>> Config JSR is more about environment config IMHO and putting it in CDI > >>>>> doesn't make sense since more or more spec works without any other > >>>>> spec - CDI in our case. > >>>> > >>>> CDI even with some config mechanism added would still work "standalone". > >>>> > >>>> > >>>>> > >>>>> This mean CDI can't be the place but should > >>>>> just be the bridge for config JSR. > >>>> > >>>> As I suggested as well. > >>>> > >>>> > >>>>> > >>>>> Plus CDI config will surely highly > >>>>> be an application config first (beans.xml should be the place then) > >>>> > >>>> Yes, app config, but beware people of writing config into beans.xml. > >>>> That is definitively in most cases not what you want. CDI should not define, > >>>> where and how config is located and formatted. CDI should provide a SPI, > >>>> where config providers can publish the configured values, so it can be > >>>> injected wherever needed. E.g. some kind of producer, that can provide > >>>> multiple objects to be injected and can benefit from some kind of callback > >>>> mechanism would be sufficient... > >>>> > >>>>> > >>>>> then environment config can be done at EE level (saying it has to > >>>>> support placeholders or any pre deployment processing). > >>>> > >>>> Config is much more complex. There is no clear border what is > >>>> environment config or environment dependent and what not. This depends on > >>>> what kind of application you have deployed. As an example the email address, > >>>> where you send error messages, can be different depenending on the > >>>> stage/environment, but this is not EE related config entry. Also what an > >>>> environment is, is not a thing that you can define completely. So I agree > >>>> not to add this complexities to CDI, I would hide them between some kind of > >>>> "config provider", as mentioned above. CDI does not need to know if the > >>>> config provided is environment dependent or not, its just what is visible at > >>>> a current runtime state... > >>>> > >>>>> > >>>>> If you put something like ProjectStage in CDI it is great but then you > >>>>> have it in JSF, CDI and finally surely all specs...same as > >>>>> converters... > >>>> > >>>> That was originally the idea, when doing a EE config JSR, but without > >>>> such standard. I agree, CDI is not the place to define them. > >>>> > >>>> > >>>>> > >>>>> Config should really be split in: > >>>>> 1) spec dependent config -> spec.xml > >>>>> 2) *common* config (a bit like javax.annotation) for environment and > >>>>> external configuration -> Config JSR > >>>> > >>>> Not 100% sure, if a get the point here... > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : > >>>>> > >>>>> well sorry to pop in so late but here are my 2cts > >>>>> > >>>>> Config JSR is more about environment config IMHO and putting it in CDI > >>>>> doesn't make sense since more or more spec works without any other > >>>>> spec - CDI in our case. This mean CDI can't be the place but should > >>>>> just be the bridge for config JSR. Plus CDI config will surely highly > >>>>> be an application config first (beans.xml should be the place then) > >>>>> then environment config can be done at EE level (saying it has to > >>>>> support placeholders or any pre deployment processing). > >>>>> > >>>>> If you put something like ProjectStage in CDI it is great but then you > >>>>> have it in JSF, CDI and finally surely all specs...same as > >>>>> converters... > >>>>> > >>>>> Config should really be split in: > >>>>> 1) spec dependent config -> spec.xml > >>>>> 2) *common* config (a bit like javax.annotation) for environment and > >>>>> external configuration -> Config JSR > >>>>> > >>>>> wdyt? > >>>>> > >>>>> > >>>>> > >>>>> Romain Manni-Bucau > >>>>> Twitter: @rmannibucau > >>>>> Blog: http://rmannibucau.wordpress.com/ > >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau > >>>>> Github: https://github.com/rmannibucau > >>>>> > >>>>> > >>>>> 2014-09-07 23:39 GMT+02:00 Werner Keil : > >>>>> > Sounds like an argument for a CDI module rather than a separate JSR > >>>>> > then?;-) > >>>>> > > >>>>> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch > >>>>> > wrote: > >>>>> >> > >>>>> >> I would not worry about CDI regarding licensing. Just the sentence > >>>>> >> was > >>>>> >> that Oracle does not want to have more ALv2 in addition to what is > >>>>> >> already > >>>>> >> there. So as long as we do things within CDI, no worries, I think. > >>>>> >> For new > >>>>> >> EE JSRs nevertheless this is a BIG issue and should be clarified by > >>>>> >> the EC! > >>>>> >> > >>>>> >> > >>>>> >> 2014-09-07 21:44 GMT+02:00 Werner Keil : > >>>>> >>> > >>>>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under > >>>>> >>> ALv2 > >>>>> >>> as a dual-license, this was discussed by EC Members but both JCP EC > >>>>> >>> and > >>>>> >>> Oracle Legal/PMO seems fine with it, and CDI is already an > >>>>> >>> essential > >>>>> >>> building block to Java EE 6/7, hence used with Glassfish, too. I > >>>>> >>> wasn't > >>>>> >>> involved in these discussions, but given CDI is especially liberal > >>>>> >>> and fully > >>>>> >>> accepted by JCP formalities and license policies, I don't really > >>>>> >>> see what > >>>>> >>> the problem wss for Anatole's JSR attempt (though I know, both > >>>>> >>> Oracle and > >>>>> >>> other EC Members/companies don't always prefer this kind of > >>>>> >>> licensing...;-) > >>>>> >>> > >>>>> >>> Werner > >>>>> >>> > >>>>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament > >>>>> >>> > >>>>> >>> wrote: > >>>>> >>>> > >>>>> >>>> Ok, this mail has me more concerned than anything. Can you > >>>>> >>>> clarify this > >>>>> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. > >>>>> >>>> > >>>>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch > >>>>> >>>> > >>>>> >>>> wrote: > >>>>> >>>>> > >>>>> >>>>> Hi All > >>>>> >>>>> > >>>>> >>>>> unfortunately things seem quite complicated: > >>>>> >>>>> > >>>>> >>>>> first of all, similarities with Deltaspike are basically not > >>>>> >>>>> accidental. The concepts we developed in Credit Suisse are very > >>>>> >>>>> similar to > >>>>> >>>>> Deltaspike, though Deltaspike was not yet born at that time. > >>>>> >>>>> Fortunately we > >>>>> >>>>> ended up with a similar kind of solution. > >>>>> >>>>> filtering still can be done. My idea is to define some kind of > >>>>> >>>>> "configuration provider", which then is dynamically asked for > >>>>> >>>>> configuration. > >>>>> >>>>> How the provider is internally organized, is completely > >>>>> >>>>> transparent to CDI. > >>>>> >>>>> This enables to have multi-layered, complex config solutions work > >>>>> >>>>> the same > >>>>> >>>>> (from a view point of CDI) like simple programmatic test > >>>>> >>>>> configurations > >>>>> >>>>> during unit tests. The config provider still can support > >>>>> >>>>> filtering and > >>>>> >>>>> dynamic resolution as commonly used in configuration systems. > >>>>> >>>>> Similarly the > >>>>> >>>>> format is basically also not fixed. Of course, would a reference > >>>>> >>>>> implementation provide a set of functionalities, but I would > >>>>> >>>>> definitively > >>>>> >>>>> not define the exact configuration mechanism as part of the CDI > >>>>> >>>>> (or even a > >>>>> >>>>> EE config JSR). Another reason, beside complexity and time, is > >>>>> >>>>> the fact that > >>>>> >>>>> different companies handle, store and manage configuration > >>>>> >>>>> differently, so a > >>>>> >>>>> mechanism must be flexible enough to accommodate these, without > >>>>> >>>>> adoption > >>>>> >>>>> rate will be low. Furthermore this flexibility also keeps doors > >>>>> >>>>> open for use > >>>>> >>>>> cases we do not know yet. > >>>>> >>>>> Also we have to separate some basically two types of > >>>>> >>>>> configuration > >>>>> >>>>> aspects: > >>>>> >>>>> > >>>>> >>>>> application config basically is injected into deployed > >>>>> >>>>> components, but > >>>>> >>>>> basically only can affect deployment to the extend it can be > >>>>> >>>>> managed and > >>>>> >>>>> injected by CDI. The basic architecture and design, how > >>>>> >>>>> application servers > >>>>> >>>>> to load and deploy are basically not affected. This type of > >>>>> >>>>> configuration > >>>>> >>>>> (mechanism) I see also as a possible addition to CDI, if we > >>>>> >>>>> really fail to > >>>>> >>>>> do something in another JSR. With CDI going for a more modular > >>>>> >>>>> design, even > >>>>> >>>>> basic configuration of CDI can be possible, given we have some > >>>>> >>>>> kind of API, > >>>>> >>>>> we can access during CDI initialization. > >>>>> >>>>> On the other side deployment configuration affects directly how > >>>>> >>>>> the > >>>>> >>>>> application server deploys the application. Configuration here > >>>>> >>>>> would allow > >>>>> >>>>> to define datasources, EJBs, transactional aspects, security, > >>>>> >>>>> persistence, > >>>>> >>>>> war and ear configurations etc. Basically everything you do as of > >>>>> >>>>> today with > >>>>> >>>>> some kind of XML file, or annotation. Hereby enabling more > >>>>> >>>>> flexibility into > >>>>> >>>>> the existing descriptors is relatively easy, but as mentioned by > >>>>> >>>>> Mark, > >>>>> >>>>> constraint. Adding more flexibility raises other subtle problems. > >>>>> >>>>> Imagine a > >>>>> >>>>> application module, e.g. a war, that defines everything it > >>>>> >>>>> requires. There > >>>>> >>>>> is no need to configure anything more on server side (with spring > >>>>> >>>>> you can do > >>>>> >>>>> this, with Java EE unfortunately not). But this has a severe > >>>>> >>>>> consequence, it > >>>>> >>>>> would make the application really portable in the sense, that it > >>>>> >>>>> can be > >>>>> >>>>> moved between different app servers (vendors) without any change > >>>>> >>>>> (ideally). > >>>>> >>>>> As a result commercial profits of some vendor companies may be > >>>>> >>>>> affected. I > >>>>> >>>>> think this is actually one of the key points, why things are > >>>>> >>>>> getting so > >>>>> >>>>> complicated in that area. > >>>>> >>>>> > >>>>> >>>>> Legal aspects also were discussed. One of them is a possible > >>>>> >>>>> legal > >>>>> >>>>> clash of ALv2 with GPL. This is the case already within > >>>>> >>>>> Glassfish, but one > >>>>> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal > >>>>> >>>>> department. At > >>>>> >>>>> the end we decided to use a BSD model. Even dual licensing > >>>>> >>>>> BSD/ALv2 could > >>>>> >>>>> theoretically be an option. If you would choose ALv2, Oracle will > >>>>> >>>>> not > >>>>> >>>>> include your RI into Glassfish, which is the RI for the EE > >>>>> >>>>> Umbrella JSR, > >>>>> >>>>> meaning your JSR will not be included into EE8. So what should we > >>>>> >>>>> do? I > >>>>> >>>>> don't have a good answer... > >>>>> >>>>> > >>>>> >>>>> So, I like to discuss configuration aspects here. Nevertheless if > >>>>> >>>>> we > >>>>> >>>>> decide to add config aspects, be aware that we might only > >>>>> >>>>> (mainly) support > >>>>> >>>>> application config, since everything else directly would impact > >>>>> >>>>> other JSRs. > >>>>> >>>>> And that is obviously quite similar to what Apache Deltaspike is > >>>>> >>>>> all about > >>>>> >>>>> ;-) > >>>>> >>>>> > >>>>> >>>>> Cheers, > >>>>> >>>>> Anatole > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : > >>>>> >>>>>> > >>>>> >>>>>> Yes, the config group also was (obviously) looking at > >>>>> >>>>>> DeltaSpikes > >>>>> >>>>>> config mechanism as well. > >>>>> >>>>>> There were others who wanted to go more into the 'filtering' > >>>>> >>>>>> approach > >>>>> >>>>>> as done on WebLogic servers (though not sure who else does that > >>>>> >>>>>> as well). > >>>>> >>>>>> You know, having all the XML configs like WEB-INF/web.xml > >>>>> >>>>>> containing > >>>>> >>>>>> placeholders and the real values only get placed in there at > >>>>> >>>>>> deployment > >>>>> >>>>>> time. I personally find this approach a bit limited from a > >>>>> >>>>>> technical > >>>>> >>>>>> perspective and it already didn't work out for me when using > >>>>> >>>>>> WebLogic (what > >>>>> >>>>>> about changing a configured value after the deployment was done? > >>>>> >>>>>> What about > >>>>> >>>>>> security? Having passwords in web.xml, unit testing, ...). > >>>>> >>>>>> There are of course also other approaches which all might have > >>>>> >>>>>> strong > >>>>> >>>>>> sides and would have needed to get discussed. > >>>>> >>>>>> > >>>>> >>>>>> But utterly the problem seems to have been legal reasons. We > >>>>> >>>>>> even > >>>>> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF > >>>>> >>>>>> project with > >>>>> >>>>>> substantial support and participation from the JBoss, DeltaSpike > >>>>> >>>>>> and TomEE > >>>>> >>>>>> communities. > >>>>> >>>>>> > >>>>> >>>>>> Anyway, the time will come when we will resurrect this effort. > >>>>> >>>>>> > >>>>> >>>>>> LieGrue, > >>>>> >>>>>> strub > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> Yep, it contains a simple but extendable notion of ProjectStage, > >>>>> >>>>>> too;-) > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament > >>>>> >>>>>> > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> Anatole, > >>>>> >>>>>> > >>>>> >>>>>> I'm wondering if some of your configuration description falls > >>>>> >>>>>> under > >>>>> >>>>>> what was put together in DeltaSpike? > >>>>> >>>>>> > >>>>> >>>>>> http://deltaspike.apache.org/configuration.html > >>>>> >>>>>> > >>>>> >>>>>> John > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch > >>>>> >>>>>> > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> Staging is not a question of xml or not xml (the "format" of > >>>>> >>>>>> config). > >>>>> >>>>>> You can do staged config also using xml, or based on a database > >>>>> >>>>>> or json > >>>>> >>>>>> config service. Staging as well as, more generally speaking, > >>>>> >>>>>> environment > >>>>> >>>>>> dependent config is more like to select/filter the right config > >>>>> >>>>>> that targets > >>>>> >>>>>> the current (runtime) environment. This might include stages, > >>>>> >>>>>> but also many > >>>>> >>>>>> other aspects are feasible and common (server, tier, ear, war, > >>>>> >>>>>> tenant ...). > >>>>> >>>>>> Since these aspects are per se very complex, it might be > >>>>> >>>>>> advisable to leave > >>>>> >>>>>> them out of any spec (even a dedicated config JSR would probably > >>>>> >>>>>> not be > >>>>> >>>>>> capable of covering these within the relatively short EE > >>>>> >>>>>> timeframe)... > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil : > >>>>> >>>>>> > >>>>> >>>>>> Jens/all, > >>>>> >>>>>> > >>>>> >>>>>> A sort of "staging" already was possible using CDI earlier, see > >>>>> >>>>>> examples like this: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war > >>>>> >>>>>> > >>>>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond the > >>>>> >>>>>> primitive, hard-coded JSF enum. > >>>>> >>>>>> > >>>>> >>>>>> If that works without XML, while still allowing flexible > >>>>> >>>>>> configuration > >>>>> >>>>>> for different stages or to add and "inject" additional stages > >>>>> >>>>>> maybe even on > >>>>> >>>>>> a tenant basis (for Cloud scenarios) I could see something like > >>>>> >>>>>> that work > >>>>> >>>>>> without XML. In the Multiconf project we managed to code > >>>>> >>>>>> everything in > >>>>> >>>>>> Python, and similar to Puppet or Chef you can configure and > >>>>> >>>>>> deploy multiple > >>>>> >>>>>> environments with it, Java EE, Spring or Play! several of them > >>>>> >>>>>> are > >>>>> >>>>>> configured this way and it requires no XML (where the container > >>>>> >>>>>> needs such > >>>>> >>>>>> files, the framework generates them;-) > >>>>> >>>>>> > >>>>> >>>>>> Werner > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, > >>>>> >>>>>> > >>>>> >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole > >>>>> >>>>>> Tresch) > >>>>> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) > >>>>> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition > >>>>> >>>>>> (Anatole Tresch (JIRA)) > >>>>> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) > >>>>> >>>>>> > >>>>> >>>>>> ------------------------------ > >>>>> >>>>>> > >>>>> >>>>>> Message: 4 > >>>>> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 > >>>>> >>>>>> From: Jens Schumann > >>>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... > >>>>> >>>>>> To: Anatole Tresch , Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> Cc: cdi-dev > >>>>> >>>>>> Message-ID: > >>>>> >>>>>> Content-Type: text/plain; charset="windows-1252" > >>>>> >>>>>> > >>>>> >>>>>> I can confirm that this approach works very well. We are using a > >>>>> >>>>>> similar approach a couple of years now, and I love the > >>>>> >>>>>> simplicity that comes > >>>>> >>>>>> with portable extensions and @Producer methods. See our public > >>>>> >>>>>> version here > >>>>> >>>>>> [1] (works since early CDI 1.0 days) . > >>>>> >>>>>> > >>>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier > >>>>> >>>>>> @Property. > >>>>> >>>>>> We support default values and type conversation for primitives > >>>>> >>>>>> and > >>>>> >>>>>> everything that has a string based constructor. The property > >>>>> >>>>>> source can be > >>>>> >>>>>> anything, from property files (default) to databases or xml > >>>>> >>>>>> files. For > >>>>> >>>>>> examples see tests here [2]. > >>>>> >>>>>> > >>>>> >>>>>> Nevertheless I am not sure if this should be part of an future > >>>>> >>>>>> CDI > >>>>> >>>>>> spec. My concerns include the bloat argument, of course. But the > >>>>> >>>>>> main reason > >>>>> >>>>>> relates to the fact that we have almost everything in the > >>>>> >>>>>> current CDI spec > >>>>> >>>>>> already. > >>>>> >>>>>> > >>>>> >>>>>> Right now I am quite happy with an custom portable extension > >>>>> >>>>>> that does > >>>>> >>>>>> everything for me. At the time we implemented the extension we > >>>>> >>>>>> realised that > >>>>> >>>>>> the "hard part" was writing an extension that links a qualified > >>>>> >>>>>> "optional > >>>>> >>>>>> injection point" with an @Producer method while supporting code > >>>>> >>>>>> based > >>>>> >>>>>> default values. Luckily I had Arne in my team who did that > >>>>> >>>>>> within a few > >>>>> >>>>>> minutes. > >>>>> >>>>>> > >>>>> >>>>>> Because of this experience I would propose that we simplify > >>>>> >>>>>> extension > >>>>> >>>>>> development such that "optional injection points" may be linked > >>>>> >>>>>> to @Produces > >>>>> >>>>>> values easily. Additionally we have to solve a few more > >>>>> >>>>>> integration issues > >>>>> >>>>>> (e.g. read-only DB access should be available during CDI > >>>>> >>>>>> startup). > >>>>> >>>>>> Everything else should be provided by portable extensions (e.g. > >>>>> >>>>>> via > >>>>> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. > >>>>> >>>>>> > >>>>> >>>>>> Jens > >>>>> >>>>>> [1] > >>>>> >>>>>> > >>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property > >>>>> >>>>>> [2] > >>>>> >>>>>> > >>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property > >>>>> >>>>>> > >>>>> >>>>>> Von: Anatole Tresch > >>>>> >>>>>> > > >>>>> >>>>>> Datum: Friday 5 September 2014 21:22 > >>>>> >>>>>> An: Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> > > >>>>> >>>>>> Cc: CDI-Dev > >>>>> >>>>>> > > >>>>> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... > >>>>> >>>>>> > >>>>> >>>>>> Hi all, > >>>>> >>>>>> > >>>>> >>>>>> I would not like to add an XML "bloated" mechanism as part of > >>>>> >>>>>> CDI 2.0. > >>>>> >>>>>> Spontaneously I would propose a more CDI like things like: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> * Adding a @Configured annotation (basically a qualifier). > >>>>> >>>>>> This > >>>>> >>>>>> can be in addition to @Inject and would allow to inject > >>>>> >>>>>> "configured" values. > >>>>> >>>>>> * Since configuration can change we may think of a (CDI) > >>>>> >>>>>> event/reinject mechanism based on config changes. By default, > >>>>> >>>>>> this is > >>>>> >>>>>> switched off and we can discuss how it would be activated, e.g. > >>>>> >>>>>> by an > >>>>> >>>>>> additional flag settable with the @Configured annotation, or an > >>>>> >>>>>> additional > >>>>> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon > >>>>> >>>>>> framework), or both. > >>>>> >>>>>> * Hereby configured values theoretically behave similar as > >>>>> >>>>>> all > >>>>> >>>>>> other injection points. They also can be qualified (the aspect > >>>>> >>>>>> of scopes, I > >>>>> >>>>>> did not yet have time to think about). The only difference is, > >>>>> >>>>>> that they are > >>>>> >>>>>> satisified using the configuration "system". > >>>>> >>>>>> * The configuration "source" itself could in the extreme > >>>>> >>>>>> simplest > >>>>> >>>>>> way be a Provider>. The CDI spec should not > >>>>> >>>>>> care about > >>>>> >>>>>> how this map is provided (XML, DB, overrides, etc). This still > >>>>> >>>>>> can be > >>>>> >>>>>> standardized later. As long as the ConfigurationSource SPI is > >>>>> >>>>>> defined, > >>>>> >>>>>> companies still can hook in the logic and level of configuration > >>>>> >>>>>> abstraction > >>>>> >>>>>> they need. > >>>>> >>>>>> * Of course, since not only Strings can be injected, we need > >>>>> >>>>>> some > >>>>> >>>>>> conversion or adapter logic as basically outlined in my blog. > >>>>> >>>>>> Also here we > >>>>> >>>>>> can add a simple SPI and let the details to the RI. > >>>>> >>>>>> > >>>>> >>>>>> Summarizing a > >>>>> >>>>>> > >>>>> >>>>>> * @Configured annotation > >>>>> >>>>>> * some kind of change event > >>>>> >>>>>> * a ConfigurationSource extends Provider> > >>>>> >>>>>> * a conversion mechanism from String to T. > >>>>> >>>>>> > >>>>> >>>>>> we get a full fledged configuration mechanism that leverages > >>>>> >>>>>> CDI. > >>>>> >>>>>> > >>>>> >>>>>> That would be my idea basically. WDYT? I will try to work that > >>>>> >>>>>> out in > >>>>> >>>>>> more details. Basically it should be implementable even with the > >>>>> >>>>>> CDI > >>>>> >>>>>> mechanism already in place with CDI 1.1. > >>>>> >>>>>> > >>>>> >>>>>> Best, > >>>>> >>>>>> Anatole > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> >: > >>>>> >>>>>> One wise man* once said "EJB was a hype specification, we added > >>>>> >>>>>> too > >>>>> >>>>>> many things to it, it became bloated. The next hype > >>>>> >>>>>> specifications are > >>>>> >>>>>> JAX-RS and CDI, careful with them" > >>>>> >>>>>> > >>>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup > >>>>> >>>>>> being > >>>>> >>>>>> bloated. > >>>>> >>>>>> > >>>>> >>>>>> Antonio > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> *David Blevin > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand > >>>>> >>>>>> > > >>>>> >>>>>> wrote: > >>>>> >>>>>> Hi all, > >>>>> >>>>>> > >>>>> >>>>>> You may have followed the rise and fall of the Java Config JSR > >>>>> >>>>>> > >>>>> >>>>>> (http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html). > >>>>> >>>>>> Anatole in CC was leading this initiative and I proposed him to > >>>>> >>>>>> join > >>>>> >>>>>> us and explore if some part of his late-JSR could be done in > >>>>> >>>>>> CDI. > >>>>> >>>>>> > >>>>> >>>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 > >>>>> >>>>>> or > >>>>> >>>>>> related solution. If we achieve to have a majority of specs to > >>>>> >>>>>> integrate > >>>>> >>>>>> with CDI, our configuration solution would therefore become a > >>>>> >>>>>> configuration > >>>>> >>>>>> system for all spec based on CDI 2.0. > >>>>> >>>>>> > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Antonio Goncalves > >>>>> >>>>>> Software architect, Java Champion and Pluralsight author > >>>>> >>>>>> > >>>>> >>>>>> Web site | > >>>>> >>>>>> Twitter | > >>>>> >>>>>> LinkedIn | > >>>>> >>>>>> > >>>>> >>>>>> Pluralsight > >>>>> >>>>>> | Paris JUG | Devoxx > >>>>> >>>>>> France > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Anatole Tresch > >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>>> Gl?rnischweg 10 > >>>>> >>>>>> CH - 8620 Wetzikon > >>>>> >>>>>> > >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>>> Twitter: @atsticks > >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>>> Google: atsticks > >>>>> >>>>>> Mobile +41-76 344 62 79 > >>>>> >>>>>> -------------- next part -------------- > >>>>> >>>>>> An HTML attachment was scrubbed... > >>>>> >>>>>> URL: > >>>>> >>>>>> > >>>>> >>>>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 > >>>>> >>>>>> *************************************** > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Anatole Tresch > >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>>> Gl?rnischweg 10 > >>>>> >>>>>> CH - 8620 Wetzikon > >>>>> >>>>>> > >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>>> Twitter: @atsticks > >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>>> Google: atsticks > >>>>> >>>>>> Mobile +41-76 344 62 79 > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> -- > >>>>> >>>>> Anatole Tresch > >>>>> >>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>> Gl?rnischweg 10 > >>>>> >>>>> CH - 8620 Wetzikon > >>>>> >>>>> > >>>>> >>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>> Twitter: @atsticks > >>>>> >>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>> Google: atsticks > >>>>> >>>>> Mobile +41-76 344 62 79 > >>>>> >>>> > >>>>> >>>> > >>>>> >>> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> -- > >>>>> >> Anatole Tresch > >>>>> >> Java Lead Engineer, JSR Spec Lead > >>>>> >> Gl?rnischweg 10 > >>>>> >> CH - 8620 Wetzikon > >>>>> >> > >>>>> >> Switzerland, Europe Zurich, GMT+1 > >>>>> >> Twitter: @atsticks > >>>>> >> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >> Google: atsticks > >>>>> >> Mobile +41-76 344 62 79 > >>>>> > > >>>>> > > >>>>> > > >>>>> > _______________________________________________ > >>>>> > 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. > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Anatole Tresch > >>>> Java Lead Engineer, JSR Spec Lead > >>>> Gl?rnischweg 10 > >>>> CH - 8620 Wetzikon > >>>> > >>>> Switzerland, Europe Zurich, GMT+1 > >>>> Twitter: @atsticks > >>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>> Google: atsticks > >>>> Mobile +41-76 344 62 79 > >>> > >>> > >>> _______________________________________________ > >>> 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. > >> > >> > >> > >> > >> -- > >> Antonio Goncalves > >> Software architect, Java Champion and Pluralsight author > >> > >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > _______________________________________________ > 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 werner.keil at gmail.com Mon Sep 8 06:20:29 2014 From: werner.keil at gmail.com (Werner Keil) Date: Mon, 8 Sep 2014 12:20:29 +0200 Subject: [cdi-dev] Enhancement proposition to JSR 330 Message-ID: Antoine/all, Thanks for sharing. I also had a discussion (in his own Spring blog) with J?rgen mainly about modularity, and the JDK minimum requirements for Spring 4.x. He confirmed, the "core" components of Spring 4.1 still run under as low as Java 6, while some modules that can be dynamically (Spring-DM aka OSGi;-) added may directly refer to Java 8, in which case you must run SE 8 or higher. So while for Java 6/7 or below version of @Inject.next this: public interface Provider extends Iterable { /** * Provides a fully-constructed and injected instance of {@code T}. */ T get(); [...] looks fine, it seemed more than consequent, if you did public interface Provider extends Iterable, Supplier { [...] in a Java 8+ case;-) Even without looking at Lambdas here in greater detail, it reused what Java SE 8 introduced. Again, that is something you, Bob, J?rgen and maybe the EE 8 Spec Leads should discuss, what the reasonable minimum requirements for @Inject.next are, if it's SE 8 or a lower version, though those of course may always stick with the previous ones... Werner On Mon, Sep 8, 2014 at 12:06 PM, 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. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition > (Romain Manni-Bucau (JIRA)) > 2. Enhancement proposition to JSR 330 (Antoine Sabot-Durand) > 3. Re: With the end of Java Config... (Werner Keil) > > > ---------------------------------------------------------------------- > > Message: 2 > Date: Mon, 8 Sep 2014 12:03:36 +0200 > From: Antoine Sabot-Durand > Subject: [cdi-dev] Enhancement proposition to JSR 330 > To: cdi-dev > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Hi all, > > > I received an answer from Bob Lee (off list). He likes te idea of us > providing a proposal document. So I worked on it this WE. > Here it is : > https://docs.google.com/document/d/1KCzqodA8uzXED5DJrEUyl0x3dOUB5mBwL4KcV8xUY_w/edit?usp=sharing > < > https://docs.google.com/document/d/1KCzqodA8uzXED5DJrEUyl0x3dOUB5mBwL4KcV8xUY_w/edit?usp=sharing > > > > Your comments and proposal are most welcome. I propose we discuss this > point during our next meeting, and if we agree on the final content send it > asap to have Bob and Juergen feeling about these suggestion. > > > Antoine > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/607a6499/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 46, Issue 42 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/8941f215/attachment.html From werner.keil at gmail.com Mon Sep 8 06:33:12 2014 From: werner.keil at gmail.com (Werner Keil) Date: Mon, 8 Sep 2014 12:33:12 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Apache allows that, especially for the Spec;-) It's sort of similar with Stephen Colebourne's "backport". A project not under "java.time" but some "org.threeten", so if what you allow them a vendor XYZ created their Apache "fork" of the Spec then they may not necessarily declare an API under "javax.*" but the are fine to do a "org.*" or other fork, and the implementation will be compatible with "their" spec. They could even do some sort of testing, or "certification" as long as they don't call it "100% Pure Java";-D Happened here for JSR-295: https://kenai.com/projects/betterbeansbinding/pages/Home To my knowledge that project did not rewrite the Spec (which would be illegal under its terms) and I don't even want to bother about whether the fork was legitimate then (before jcp.next) at all, since both projects are now dead, but if a vendor wanted, they could fork projects like "BetterBeanValidation" or "TDI" instead of "CDI" (just like car vendors do with those names for often the same technology;-) Werner On Mon, Sep 8, 2014 at 12:11 PM, Pete Muir wrote: > > On 8 Sep 2014, at 11:06, Werner Keil wrote: > > > As a side note, if the BV Spec is now Apache, those who want to write > "their own flavor" of Spec and API can do so in these cases;-) > > Which is also why Anatole (and other EC Members talking to Oracle Legal, > etc.) said, Oracle "tolerates" the Apache Licensing of even the Spec > Document, but it is a two-headed sword for compatibility. > > > > A vendor taking that spec and adding their own "appendix" would not be > sued (like for other parts of the Java ecosystem;-p) but it may end up as a > proprietary feature to that container alone. > > Right, but at this point they are no longer implementing ?CDI?, they are > now implementing ?vendors-variation-of-CDI?... > > > > > If let's say a simple desktop app has no need for an extensible "stage" > concept and API, then that's a perfect example where optionality just like > under MEEP 8 makes sense in the SE/EE world, too. Not because of size, but > choice and keeping the burden for developers (and implementors, if they > don't want to use it) lower than e.g. with SE 8 and 5 different (mandatory) > Date/Time APIs;-| > > > > Werner > > > > On Mon, Sep 8, 2014 at 11:51 AM, Romain Manni-Bucau < > rmannibucau at gmail.com> wrote: > > @Antonio: -1 for an appendix, bean validation is the example it is > > broken. Idea is awesome, everybody liked it so it was added -> great. > > Here everybody already agrees it is good so no need of "staging" phase > > IMHO. BV appendix was not the API used so it broke apps using it. SO > > using proprietary stuff is the same, it basically mean an appendix > > spec for something not under discussion (regarding its need) is IMHO > > useless. > > > > > > Romain Manni-Bucau > > Twitter: @rmannibucau > > Blog: http://rmannibucau.wordpress.com/ > > LinkedIn: http://fr.linkedin.com/in/rmannibucau > > Github: https://github.com/rmannibucau > > > > > > 2014-09-08 10:29 GMT+02:00 Werner Keil : > > > Hi, > > > > > > If it's not really usable as API or annotation I don't see much value > in > > > adding some "how to" or intent for the future into the Spec Document. > > > > > > If it was to become a part of CDI 2, there's nothing against > optionality > > > like MEEP 8 or JSR 363 already practice on the SE/EE side either. > > > > > > Agorava/DeltaSpike demonstrate how true modularity work, similar to > the JSRs > > > mentioned above, where you have multiple module JARs/bundles instead > of a > > > big monolithic one. Some JSRs like Batch also declared separate > "annotation" > > > modules, so that's what CDI 2 should also do if it was a feature > Inside of > > > it. > > > Calling some features optional if they're not used by every > implementation > > > allows them to chose. That was also the main value of keeping @Inject a > > > separate "module" under CDI. It was never included into a JDK but used > > > independently. > > > > > > The core of a Config module would ideally work in SE, but CDI 2 already > > > declared an aim to have some modules work under SE. > > > > > > Werner > > > > > > Am 08.09.2014 09:47 schrieb "Antonio Goncalves" > > > : > > > > > >> Hi all, > > >> > > >> I really have some concerns about adding configuration into CDI but I > can > > >> see benefits too. And what about adding it... and not adding it at > the same > > >> time ? In Bean Validation 1.0, the Expert Group decided not to include > > >> method-level validation in the spec (it was included in 1.1). But > what they > > >> did is to add it as a proposal in the Appendix. > > >> > > >> If we feel some configuration should get in, why not have a proposal > in > > >> the Appendix of CDI 2.0 ? It could then be implemented by Weld (and > > >> OpenWebBeans if they feel like it). And then, if it's successful and > things > > >> get easier, get its own JSR for Java EE 9. > > >> > > >> WDYT ? > > >> > > >> Antonio > > >> > > >> On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau < > rmannibucau at gmail.com> > > >> wrote: > > >>> > > >>> Hmm > > >>> > > >>> I see config jsr as a jse spec which would allow EE injections in > config > > >>> components in EE containers (exactly like jbatch). > > >>> > > >>> This way it can be used without any container or with any container > > >>> easily. Only limit will be to not do something cdi/known containers > will not > > >>> support I think. > > >>> > > >>> Not sure EE side is needed today, a lot can already be done without > it > > >>> and it can be enhanced later adding some integration words. > > >>> > > >>> Le 8 sept. 2014 00:01, "Anatole Tresch" a > ?crit : > > >>> > > >>>> Hi Romain > > >>>> > > >>>> just a few remarks inline... > > >>>> > > >>>> Summarizing > > >>>> 1) injection of values, reinjection, feedback on config changes can > all > > >>>> be done with already existing features (producers, extensions). > > >>>> 2) configuring/bootstrapping CDI itself, e.g. configuration, is > targeted > > >>>> with CDI 2.0 (see spec failing) > > >>>> > > >>>> So basically we could try to look if there is enough interest to > > >>>> standardize configuration in a more general way. For deployment > aspects we > > >>>> need an EE JSR, for the rest, another SE standard may be an option > as > > >>>> well... tbd... > > >>>> > > >>>> -Anatole > > >>>> > > >>>> > > >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau >: > > >>>>> > > >>>>> well sorry to pop in so late but here are my 2cts > > >>>> > > >>>> easy ;) > > >>>> > > >>>>> > > >>>>> Config JSR is more about environment config IMHO and putting it in > CDI > > >>>>> doesn't make sense since more or more spec works without any other > > >>>>> spec - CDI in our case. > > >>>> > > >>>> CDI even with some config mechanism added would still work > "standalone". > > >>>> > > >>>> > > >>>>> > > >>>>> This mean CDI can't be the place but should > > >>>>> just be the bridge for config JSR. > > >>>> > > >>>> As I suggested as well. > > >>>> > > >>>> > > >>>>> > > >>>>> Plus CDI config will surely highly > > >>>>> be an application config first (beans.xml should be the place then) > > >>>> > > >>>> Yes, app config, but beware people of writing config into beans.xml. > > >>>> That is definitively in most cases not what you want. CDI should > not define, > > >>>> where and how config is located and formatted. CDI should provide a > SPI, > > >>>> where config providers can publish the configured values, so it can > be > > >>>> injected wherever needed. E.g. some kind of producer, that can > provide > > >>>> multiple objects to be injected and can benefit from some kind of > callback > > >>>> mechanism would be sufficient... > > >>>> > > >>>>> > > >>>>> then environment config can be done at EE level (saying it has to > > >>>>> support placeholders or any pre deployment processing). > > >>>> > > >>>> Config is much more complex. There is no clear border what is > > >>>> environment config or environment dependent and what not. This > depends on > > >>>> what kind of application you have deployed. As an example the email > address, > > >>>> where you send error messages, can be different depenending on the > > >>>> stage/environment, but this is not EE related config entry. Also > what an > > >>>> environment is, is not a thing that you can define completely. So I > agree > > >>>> not to add this complexities to CDI, I would hide them between some > kind of > > >>>> "config provider", as mentioned above. CDI does not need to know if > the > > >>>> config provided is environment dependent or not, its just what is > visible at > > >>>> a current runtime state... > > >>>> > > >>>>> > > >>>>> If you put something like ProjectStage in CDI it is great but then > you > > >>>>> have it in JSF, CDI and finally surely all specs...same as > > >>>>> converters... > > >>>> > > >>>> That was originally the idea, when doing a EE config JSR, but > without > > >>>> such standard. I agree, CDI is not the place to define them. > > >>>> > > >>>> > > >>>>> > > >>>>> Config should really be split in: > > >>>>> 1) spec dependent config -> spec.xml > > >>>>> 2) *common* config (a bit like javax.annotation) for environment > and > > >>>>> external configuration -> Config JSR > > >>>> > > >>>> Not 100% sure, if a get the point here... > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau >: > > >>>>> > > >>>>> well sorry to pop in so late but here are my 2cts > > >>>>> > > >>>>> Config JSR is more about environment config IMHO and putting it in > CDI > > >>>>> doesn't make sense since more or more spec works without any other > > >>>>> spec - CDI in our case. This mean CDI can't be the place but should > > >>>>> just be the bridge for config JSR. Plus CDI config will surely > highly > > >>>>> be an application config first (beans.xml should be the place then) > > >>>>> then environment config can be done at EE level (saying it has to > > >>>>> support placeholders or any pre deployment processing). > > >>>>> > > >>>>> If you put something like ProjectStage in CDI it is great but then > you > > >>>>> have it in JSF, CDI and finally surely all specs...same as > > >>>>> converters... > > >>>>> > > >>>>> Config should really be split in: > > >>>>> 1) spec dependent config -> spec.xml > > >>>>> 2) *common* config (a bit like javax.annotation) for environment > and > > >>>>> external configuration -> Config JSR > > >>>>> > > >>>>> wdyt? > > >>>>> > > >>>>> > > >>>>> > > >>>>> Romain Manni-Bucau > > >>>>> Twitter: @rmannibucau > > >>>>> Blog: http://rmannibucau.wordpress.com/ > > >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau > > >>>>> Github: https://github.com/rmannibucau > > >>>>> > > >>>>> > > >>>>> 2014-09-07 23:39 GMT+02:00 Werner Keil : > > >>>>> > Sounds like an argument for a CDI module rather than a separate > JSR > > >>>>> > then?;-) > > >>>>> > > > >>>>> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch < > atsticks at gmail.com> > > >>>>> > wrote: > > >>>>> >> > > >>>>> >> I would not worry about CDI regarding licensing. Just the > sentence > > >>>>> >> was > > >>>>> >> that Oracle does not want to have more ALv2 in addition to what > is > > >>>>> >> already > > >>>>> >> there. So as long as we do things within CDI, no worries, I > think. > > >>>>> >> For new > > >>>>> >> EE JSRs nevertheless this is a BIG issue and should be > clarified by > > >>>>> >> the EC! > > >>>>> >> > > >>>>> >> > > >>>>> >> 2014-09-07 21:44 GMT+02:00 Werner Keil : > > >>>>> >>> > > >>>>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec > under > > >>>>> >>> ALv2 > > >>>>> >>> as a dual-license, this was discussed by EC Members but both > JCP EC > > >>>>> >>> and > > >>>>> >>> Oracle Legal/PMO seems fine with it, and CDI is already an > > >>>>> >>> essential > > >>>>> >>> building block to Java EE 6/7, hence used with Glassfish, too. > I > > >>>>> >>> wasn't > > >>>>> >>> involved in these discussions, but given CDI is especially > liberal > > >>>>> >>> and fully > > >>>>> >>> accepted by JCP formalities and license policies, I don't > really > > >>>>> >>> see what > > >>>>> >>> the problem wss for Anatole's JSR attempt (though I know, both > > >>>>> >>> Oracle and > > >>>>> >>> other EC Members/companies don't always prefer this kind of > > >>>>> >>> licensing...;-) > > >>>>> >>> > > >>>>> >>> Werner > > >>>>> >>> > > >>>>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament > > >>>>> >>> > > >>>>> >>> wrote: > > >>>>> >>>> > > >>>>> >>>> Ok, this mail has me more concerned than anything. Can you > > >>>>> >>>> clarify this > > >>>>> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. > > >>>>> >>>> > > >>>>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch > > >>>>> >>>> > > >>>>> >>>> wrote: > > >>>>> >>>>> > > >>>>> >>>>> Hi All > > >>>>> >>>>> > > >>>>> >>>>> unfortunately things seem quite complicated: > > >>>>> >>>>> > > >>>>> >>>>> first of all, similarities with Deltaspike are basically not > > >>>>> >>>>> accidental. The concepts we developed in Credit Suisse are > very > > >>>>> >>>>> similar to > > >>>>> >>>>> Deltaspike, though Deltaspike was not yet born at that time. > > >>>>> >>>>> Fortunately we > > >>>>> >>>>> ended up with a similar kind of solution. > > >>>>> >>>>> filtering still can be done. My idea is to define some kind > of > > >>>>> >>>>> "configuration provider", which then is dynamically asked for > > >>>>> >>>>> configuration. > > >>>>> >>>>> How the provider is internally organized, is completely > > >>>>> >>>>> transparent to CDI. > > >>>>> >>>>> This enables to have multi-layered, complex config solutions > work > > >>>>> >>>>> the same > > >>>>> >>>>> (from a view point of CDI) like simple programmatic test > > >>>>> >>>>> configurations > > >>>>> >>>>> during unit tests. The config provider still can support > > >>>>> >>>>> filtering and > > >>>>> >>>>> dynamic resolution as commonly used in configuration systems. > > >>>>> >>>>> Similarly the > > >>>>> >>>>> format is basically also not fixed. Of course, would a > reference > > >>>>> >>>>> implementation provide a set of functionalities, but I would > > >>>>> >>>>> definitively > > >>>>> >>>>> not define the exact configuration mechanism as part of the > CDI > > >>>>> >>>>> (or even a > > >>>>> >>>>> EE config JSR). Another reason, beside complexity and time, > is > > >>>>> >>>>> the fact that > > >>>>> >>>>> different companies handle, store and manage configuration > > >>>>> >>>>> differently, so a > > >>>>> >>>>> mechanism must be flexible enough to accommodate these, > without > > >>>>> >>>>> adoption > > >>>>> >>>>> rate will be low. Furthermore this flexibility also keeps > doors > > >>>>> >>>>> open for use > > >>>>> >>>>> cases we do not know yet. > > >>>>> >>>>> Also we have to separate some basically two types of > > >>>>> >>>>> configuration > > >>>>> >>>>> aspects: > > >>>>> >>>>> > > >>>>> >>>>> application config basically is injected into deployed > > >>>>> >>>>> components, but > > >>>>> >>>>> basically only can affect deployment to the extend it can be > > >>>>> >>>>> managed and > > >>>>> >>>>> injected by CDI. The basic architecture and design, how > > >>>>> >>>>> application servers > > >>>>> >>>>> to load and deploy are basically not affected. This type of > > >>>>> >>>>> configuration > > >>>>> >>>>> (mechanism) I see also as a possible addition to CDI, if we > > >>>>> >>>>> really fail to > > >>>>> >>>>> do something in another JSR. With CDI going for a more > modular > > >>>>> >>>>> design, even > > >>>>> >>>>> basic configuration of CDI can be possible, given we have > some > > >>>>> >>>>> kind of API, > > >>>>> >>>>> we can access during CDI initialization. > > >>>>> >>>>> On the other side deployment configuration affects directly > how > > >>>>> >>>>> the > > >>>>> >>>>> application server deploys the application. Configuration > here > > >>>>> >>>>> would allow > > >>>>> >>>>> to define datasources, EJBs, transactional aspects, security, > > >>>>> >>>>> persistence, > > >>>>> >>>>> war and ear configurations etc. Basically everything you do > as of > > >>>>> >>>>> today with > > >>>>> >>>>> some kind of XML file, or annotation. Hereby enabling more > > >>>>> >>>>> flexibility into > > >>>>> >>>>> the existing descriptors is relatively easy, but as > mentioned by > > >>>>> >>>>> Mark, > > >>>>> >>>>> constraint. Adding more flexibility raises other subtle > problems. > > >>>>> >>>>> Imagine a > > >>>>> >>>>> application module, e.g. a war, that defines everything it > > >>>>> >>>>> requires. There > > >>>>> >>>>> is no need to configure anything more on server side (with > spring > > >>>>> >>>>> you can do > > >>>>> >>>>> this, with Java EE unfortunately not). But this has a severe > > >>>>> >>>>> consequence, it > > >>>>> >>>>> would make the application really portable in the sense, > that it > > >>>>> >>>>> can be > > >>>>> >>>>> moved between different app servers (vendors) without any > change > > >>>>> >>>>> (ideally). > > >>>>> >>>>> As a result commercial profits of some vendor companies may > be > > >>>>> >>>>> affected. I > > >>>>> >>>>> think this is actually one of the key points, why things are > > >>>>> >>>>> getting so > > >>>>> >>>>> complicated in that area. > > >>>>> >>>>> > > >>>>> >>>>> Legal aspects also were discussed. One of them is a possible > > >>>>> >>>>> legal > > >>>>> >>>>> clash of ALv2 with GPL. This is the case already within > > >>>>> >>>>> Glassfish, but one > > >>>>> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal > > >>>>> >>>>> department. At > > >>>>> >>>>> the end we decided to use a BSD model. Even dual licensing > > >>>>> >>>>> BSD/ALv2 could > > >>>>> >>>>> theoretically be an option. If you would choose ALv2, Oracle > will > > >>>>> >>>>> not > > >>>>> >>>>> include your RI into Glassfish, which is the RI for the EE > > >>>>> >>>>> Umbrella JSR, > > >>>>> >>>>> meaning your JSR will not be included into EE8. So what > should we > > >>>>> >>>>> do? I > > >>>>> >>>>> don't have a good answer... > > >>>>> >>>>> > > >>>>> >>>>> So, I like to discuss configuration aspects here. > Nevertheless if > > >>>>> >>>>> we > > >>>>> >>>>> decide to add config aspects, be aware that we might only > > >>>>> >>>>> (mainly) support > > >>>>> >>>>> application config, since everything else directly would > impact > > >>>>> >>>>> other JSRs. > > >>>>> >>>>> And that is obviously quite similar to what Apache > Deltaspike is > > >>>>> >>>>> all about > > >>>>> >>>>> ;-) > > >>>>> >>>>> > > >>>>> >>>>> Cheers, > > >>>>> >>>>> Anatole > > >>>>> >>>>> > > >>>>> >>>>> > > >>>>> >>>>> > > >>>>> >>>>> > > >>>>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg >: > > >>>>> >>>>>> > > >>>>> >>>>>> Yes, the config group also was (obviously) looking at > > >>>>> >>>>>> DeltaSpikes > > >>>>> >>>>>> config mechanism as well. > > >>>>> >>>>>> There were others who wanted to go more into the 'filtering' > > >>>>> >>>>>> approach > > >>>>> >>>>>> as done on WebLogic servers (though not sure who else does > that > > >>>>> >>>>>> as well). > > >>>>> >>>>>> You know, having all the XML configs like WEB-INF/web.xml > > >>>>> >>>>>> containing > > >>>>> >>>>>> placeholders and the real values only get placed in there at > > >>>>> >>>>>> deployment > > >>>>> >>>>>> time. I personally find this approach a bit limited from a > > >>>>> >>>>>> technical > > >>>>> >>>>>> perspective and it already didn't work out for me when using > > >>>>> >>>>>> WebLogic (what > > >>>>> >>>>>> about changing a configured value after the deployment was > done? > > >>>>> >>>>>> What about > > >>>>> >>>>>> security? Having passwords in web.xml, unit testing, ...). > > >>>>> >>>>>> There are of course also other approaches which all might > have > > >>>>> >>>>>> strong > > >>>>> >>>>>> sides and would have needed to get discussed. > > >>>>> >>>>>> > > >>>>> >>>>>> But utterly the problem seems to have been legal reasons. We > > >>>>> >>>>>> even > > >>>>> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an > ASF > > >>>>> >>>>>> project with > > >>>>> >>>>>> substantial support and participation from the JBoss, > DeltaSpike > > >>>>> >>>>>> and TomEE > > >>>>> >>>>>> communities. > > >>>>> >>>>>> > > >>>>> >>>>>> Anyway, the time will come when we will resurrect this > effort. > > >>>>> >>>>>> > > >>>>> >>>>>> LieGrue, > > >>>>> >>>>>> strub > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil > > >>>>> >>>>>> wrote: > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> Yep, it contains a simple but extendable notion of > ProjectStage, > > >>>>> >>>>>> too;-) > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament > > >>>>> >>>>>> > > >>>>> >>>>>> wrote: > > >>>>> >>>>>> > > >>>>> >>>>>> Anatole, > > >>>>> >>>>>> > > >>>>> >>>>>> I'm wondering if some of your configuration description > falls > > >>>>> >>>>>> under > > >>>>> >>>>>> what was put together in DeltaSpike? > > >>>>> >>>>>> > > >>>>> >>>>>> http://deltaspike.apache.org/configuration.html > > >>>>> >>>>>> > > >>>>> >>>>>> John > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch > > >>>>> >>>>>> > > >>>>> >>>>>> wrote: > > >>>>> >>>>>> > > >>>>> >>>>>> Staging is not a question of xml or not xml (the "format" of > > >>>>> >>>>>> config). > > >>>>> >>>>>> You can do staged config also using xml, or based on a > database > > >>>>> >>>>>> or json > > >>>>> >>>>>> config service. Staging as well as, more generally speaking, > > >>>>> >>>>>> environment > > >>>>> >>>>>> dependent config is more like to select/filter the right > config > > >>>>> >>>>>> that targets > > >>>>> >>>>>> the current (runtime) environment. This might include > stages, > > >>>>> >>>>>> but also many > > >>>>> >>>>>> other aspects are feasible and common (server, tier, ear, > war, > > >>>>> >>>>>> tenant ...). > > >>>>> >>>>>> Since these aspects are per se very complex, it might be > > >>>>> >>>>>> advisable to leave > > >>>>> >>>>>> them out of any spec (even a dedicated config JSR would > probably > > >>>>> >>>>>> not be > > >>>>> >>>>>> capable of covering these within the relatively short EE > > >>>>> >>>>>> timeframe)... > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil < > werner.keil at gmail.com>: > > >>>>> >>>>>> > > >>>>> >>>>>> Jens/all, > > >>>>> >>>>>> > > >>>>> >>>>>> A sort of "staging" already was possible using CDI earlier, > see > > >>>>> >>>>>> examples like this: > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war > > >>>>> >>>>>> > > >>>>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond > the > > >>>>> >>>>>> primitive, hard-coded JSF enum. > > >>>>> >>>>>> > > >>>>> >>>>>> If that works without XML, while still allowing flexible > > >>>>> >>>>>> configuration > > >>>>> >>>>>> for different stages or to add and "inject" additional > stages > > >>>>> >>>>>> maybe even on > > >>>>> >>>>>> a tenant basis (for Cloud scenarios) I could see something > like > > >>>>> >>>>>> that work > > >>>>> >>>>>> without XML. In the Multiconf project we managed to code > > >>>>> >>>>>> everything in > > >>>>> >>>>>> Python, and similar to Puppet or Chef you can configure and > > >>>>> >>>>>> deploy multiple > > >>>>> >>>>>> environments with it, Java EE, Spring or Play! several of > them > > >>>>> >>>>>> are > > >>>>> >>>>>> configured this way and it requires no XML (where the > container > > >>>>> >>>>>> needs such > > >>>>> >>>>>> files, the framework generates them;-) > > >>>>> >>>>>> > > >>>>> >>>>>> Werner > > >>>>> >>>>>> > > >>>>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, > > >>>>> >>>>>> > > >>>>> >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github > (Anatole > > >>>>> >>>>>> Tresch) > > >>>>> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) > > >>>>> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() > definition > > >>>>> >>>>>> (Anatole Tresch (JIRA)) > > >>>>> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) > > >>>>> >>>>>> > > >>>>> >>>>>> ------------------------------ > > >>>>> >>>>>> > > >>>>> >>>>>> Message: 4 > > >>>>> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 > > >>>>> >>>>>> From: Jens Schumann > > >>>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... > > >>>>> >>>>>> To: Anatole Tresch , Antonio Goncalves > > >>>>> >>>>>> > > >>>>> >>>>>> Cc: cdi-dev > > >>>>> >>>>>> Message-ID: > > >>>>> >>>>>> Content-Type: text/plain; charset="windows-1252" > > >>>>> >>>>>> > > >>>>> >>>>>> I can confirm that this approach works very well. We are > using a > > >>>>> >>>>>> similar approach a couple of years now, and I love the > > >>>>> >>>>>> simplicity that comes > > >>>>> >>>>>> with portable extensions and @Producer methods. See our > public > > >>>>> >>>>>> version here > > >>>>> >>>>>> [1] (works since early CDI 1.0 days) . > > >>>>> >>>>>> > > >>>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier > > >>>>> >>>>>> @Property. > > >>>>> >>>>>> We support default values and type conversation for > primitives > > >>>>> >>>>>> and > > >>>>> >>>>>> everything that has a string based constructor. The property > > >>>>> >>>>>> source can be > > >>>>> >>>>>> anything, from property files (default) to databases or xml > > >>>>> >>>>>> files. For > > >>>>> >>>>>> examples see tests here [2]. > > >>>>> >>>>>> > > >>>>> >>>>>> Nevertheless I am not sure if this should be part of an > future > > >>>>> >>>>>> CDI > > >>>>> >>>>>> spec. My concerns include the bloat argument, of course. > But the > > >>>>> >>>>>> main reason > > >>>>> >>>>>> relates to the fact that we have almost everything in the > > >>>>> >>>>>> current CDI spec > > >>>>> >>>>>> already. > > >>>>> >>>>>> > > >>>>> >>>>>> Right now I am quite happy with an custom portable extension > > >>>>> >>>>>> that does > > >>>>> >>>>>> everything for me. At the time we implemented the extension > we > > >>>>> >>>>>> realised that > > >>>>> >>>>>> the "hard part" was writing an extension that links a > qualified > > >>>>> >>>>>> "optional > > >>>>> >>>>>> injection point" with an @Producer method while supporting > code > > >>>>> >>>>>> based > > >>>>> >>>>>> default values. Luckily I had Arne in my team who did that > > >>>>> >>>>>> within a few > > >>>>> >>>>>> minutes. > > >>>>> >>>>>> > > >>>>> >>>>>> Because of this experience I would propose that we simplify > > >>>>> >>>>>> extension > > >>>>> >>>>>> development such that "optional injection points" may be > linked > > >>>>> >>>>>> to @Produces > > >>>>> >>>>>> values easily. Additionally we have to solve a few more > > >>>>> >>>>>> integration issues > > >>>>> >>>>>> (e.g. read-only DB access should be available during CDI > > >>>>> >>>>>> startup). > > >>>>> >>>>>> Everything else should be provided by portable extensions > (e.g. > > >>>>> >>>>>> via > > >>>>> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. > > >>>>> >>>>>> > > >>>>> >>>>>> Jens > > >>>>> >>>>>> [1] > > >>>>> >>>>>> > > >>>>> >>>>>> > https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property > > >>>>> >>>>>> [2] > > >>>>> >>>>>> > > >>>>> >>>>>> > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property > > >>>>> >>>>>> > > >>>>> >>>>>> Von: Anatole Tresch > > >>>>> >>>>>> > > > >>>>> >>>>>> Datum: Friday 5 September 2014 21:22 > > >>>>> >>>>>> An: Antonio Goncalves > > >>>>> >>>>>> > > >>>>> >>>>>> antonio.goncalves at gmail.com>> > > >>>>> >>>>>> Cc: CDI-Dev > > >>>>> >>>>>> > > > >>>>> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... > > >>>>> >>>>>> > > >>>>> >>>>>> Hi all, > > >>>>> >>>>>> > > >>>>> >>>>>> I would not like to add an XML "bloated" mechanism as part > of > > >>>>> >>>>>> CDI 2.0. > > >>>>> >>>>>> Spontaneously I would propose a more CDI like things like: > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> * Adding a @Configured annotation (basically a > qualifier). > > >>>>> >>>>>> This > > >>>>> >>>>>> can be in addition to @Inject and would allow to inject > > >>>>> >>>>>> "configured" values. > > >>>>> >>>>>> * Since configuration can change we may think of a (CDI) > > >>>>> >>>>>> event/reinject mechanism based on config changes. By > default, > > >>>>> >>>>>> this is > > >>>>> >>>>>> switched off and we can discuss how it would be activated, > e.g. > > >>>>> >>>>>> by an > > >>>>> >>>>>> additional flag settable with the @Configured annotation, > or an > > >>>>> >>>>>> additional > > >>>>> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon > > >>>>> >>>>>> framework), or both. > > >>>>> >>>>>> * Hereby configured values theoretically behave similar > as > > >>>>> >>>>>> all > > >>>>> >>>>>> other injection points. They also can be qualified (the > aspect > > >>>>> >>>>>> of scopes, I > > >>>>> >>>>>> did not yet have time to think about). The only difference > is, > > >>>>> >>>>>> that they are > > >>>>> >>>>>> satisified using the configuration "system". > > >>>>> >>>>>> * The configuration "source" itself could in the extreme > > >>>>> >>>>>> simplest > > >>>>> >>>>>> way be a Provider>. The CDI spec should > not > > >>>>> >>>>>> care about > > >>>>> >>>>>> how this map is provided (XML, DB, overrides, etc). This > still > > >>>>> >>>>>> can be > > >>>>> >>>>>> standardized later. As long as the ConfigurationSource SPI > is > > >>>>> >>>>>> defined, > > >>>>> >>>>>> companies still can hook in the logic and level of > configuration > > >>>>> >>>>>> abstraction > > >>>>> >>>>>> they need. > > >>>>> >>>>>> * Of course, since not only Strings can be injected, we > need > > >>>>> >>>>>> some > > >>>>> >>>>>> conversion or adapter logic as basically outlined in my > blog. > > >>>>> >>>>>> Also here we > > >>>>> >>>>>> can add a simple SPI and let the details to the RI. > > >>>>> >>>>>> > > >>>>> >>>>>> Summarizing a > > >>>>> >>>>>> > > >>>>> >>>>>> * @Configured annotation > > >>>>> >>>>>> * some kind of change event > > >>>>> >>>>>> * a ConfigurationSource extends > Provider> > > >>>>> >>>>>> * a conversion mechanism from String to T. > > >>>>> >>>>>> > > >>>>> >>>>>> we get a full fledged configuration mechanism that leverages > > >>>>> >>>>>> CDI. > > >>>>> >>>>>> > > >>>>> >>>>>> That would be my idea basically. WDYT? I will try to work > that > > >>>>> >>>>>> out in > > >>>>> >>>>>> more details. Basically it should be implementable even > with the > > >>>>> >>>>>> CDI > > >>>>> >>>>>> mechanism already in place with CDI 1.1. > > >>>>> >>>>>> > > >>>>> >>>>>> Best, > > >>>>> >>>>>> Anatole > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves > > >>>>> >>>>>> > > >>>>> >>>>>> antonio.goncalves at gmail.com>>: > > >>>>> >>>>>> One wise man* once said "EJB was a hype specification, we > added > > >>>>> >>>>>> too > > >>>>> >>>>>> many things to it, it became bloated. The next hype > > >>>>> >>>>>> specifications are > > >>>>> >>>>>> JAX-RS and CDI, careful with them" > > >>>>> >>>>>> > > >>>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup > > >>>>> >>>>>> being > > >>>>> >>>>>> bloated. > > >>>>> >>>>>> > > >>>>> >>>>>> Antonio > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> *David Blevin > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand > > >>>>> >>>>>> > > > >>>>> >>>>>> wrote: > > >>>>> >>>>>> Hi all, > > >>>>> >>>>>> > > >>>>> >>>>>> You may have followed the rise and fall of the Java Config > JSR > > >>>>> >>>>>> > > >>>>> >>>>>> ( > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > ). > > >>>>> >>>>>> Anatole in CC was leading this initiative and I proposed > him to > > >>>>> >>>>>> join > > >>>>> >>>>>> us and explore if some part of his late-JSR could be done in > > >>>>> >>>>>> CDI. > > >>>>> >>>>>> > > >>>>> >>>>>> I?m mainly thinking of > https://issues.jboss.org/browse/CDI-123 > > >>>>> >>>>>> or > > >>>>> >>>>>> related solution. If we achieve to have a majority of specs > to > > >>>>> >>>>>> integrate > > >>>>> >>>>>> with CDI, our configuration solution would therefore become > a > > >>>>> >>>>>> configuration > > >>>>> >>>>>> system for all spec based on CDI 2.0. > > >>>>> >>>>>> > > >>>>> >>>>>> 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. > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> -- > > >>>>> >>>>>> Antonio Goncalves > > >>>>> >>>>>> Software architect, Java Champion and Pluralsight author > > >>>>> >>>>>> > > >>>>> >>>>>> Web site | > > >>>>> >>>>>> Twitter | > > >>>>> >>>>>> LinkedIn | > > >>>>> >>>>>> > > >>>>> >>>>>> Pluralsight< > http://pluralsight.com/training/Authors/Details/antonio-goncalves> > > >>>>> >>>>>> | Paris JUG | Devoxx > > >>>>> >>>>>> France > > >>>>> >>>>>> > > >>>>> >>>>>> _______________________________________________ > > >>>>> >>>>>> 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. > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> -- > > >>>>> >>>>>> Anatole Tresch > > >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead > > >>>>> >>>>>> Gl?rnischweg 10 > > >>>>> >>>>>> CH - 8620 Wetzikon > > >>>>> >>>>>> > > >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 > > >>>>> >>>>>> Twitter: @atsticks > > >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > > >>>>> >>>>>> Google: atsticks > > >>>>> >>>>>> Mobile +41-76 344 62 79 > > >>>>> >>>>>> -------------- next part -------------- > > >>>>> >>>>>> An HTML attachment was scrubbed... > > >>>>> >>>>>> URL: > > >>>>> >>>>>> > > >>>>> >>>>>> > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 > > >>>>> >>>>>> *************************************** > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> _______________________________________________ > > >>>>> >>>>>> 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. > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> -- > > >>>>> >>>>>> Anatole Tresch > > >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead > > >>>>> >>>>>> Gl?rnischweg 10 > > >>>>> >>>>>> CH - 8620 Wetzikon > > >>>>> >>>>>> > > >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 > > >>>>> >>>>>> Twitter: @atsticks > > >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > > >>>>> >>>>>> Google: atsticks > > >>>>> >>>>>> Mobile +41-76 344 62 79 > > >>>>> >>>>>> > > >>>>> >>>>>> _______________________________________________ > > >>>>> >>>>>> 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. > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> > > >>>>> >>>>>> _______________________________________________ > > >>>>> >>>>>> 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. > > >>>>> >>>>> > > >>>>> >>>>> > > >>>>> >>>>> > > >>>>> >>>>> > > >>>>> >>>>> -- > > >>>>> >>>>> Anatole Tresch > > >>>>> >>>>> Java Lead Engineer, JSR Spec Lead > > >>>>> >>>>> Gl?rnischweg 10 > > >>>>> >>>>> CH - 8620 Wetzikon > > >>>>> >>>>> > > >>>>> >>>>> Switzerland, Europe Zurich, GMT+1 > > >>>>> >>>>> Twitter: @atsticks > > >>>>> >>>>> Blogs: http://javaremarkables.blogspot.ch/ > > >>>>> >>>>> Google: atsticks > > >>>>> >>>>> Mobile +41-76 344 62 79 > > >>>>> >>>> > > >>>>> >>>> > > >>>>> >>> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> -- > > >>>>> >> Anatole Tresch > > >>>>> >> Java Lead Engineer, JSR Spec Lead > > >>>>> >> Gl?rnischweg 10 > > >>>>> >> CH - 8620 Wetzikon > > >>>>> >> > > >>>>> >> Switzerland, Europe Zurich, GMT+1 > > >>>>> >> Twitter: @atsticks > > >>>>> >> Blogs: http://javaremarkables.blogspot.ch/ > > >>>>> >> Google: atsticks > > >>>>> >> Mobile +41-76 344 62 79 > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > _______________________________________________ > > >>>>> > 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. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> Anatole Tresch > > >>>> Java Lead Engineer, JSR Spec Lead > > >>>> Gl?rnischweg 10 > > >>>> CH - 8620 Wetzikon > > >>>> > > >>>> Switzerland, Europe Zurich, GMT+1 > > >>>> Twitter: @atsticks > > >>>> Blogs: http://javaremarkables.blogspot.ch/ > > >>>> Google: atsticks > > >>>> Mobile +41-76 344 62 79 > > >>> > > >>> > > >>> _______________________________________________ > > >>> 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. > > >> > > >> > > >> > > >> > > >> -- > > >> Antonio Goncalves > > >> Software architect, Java Champion and Pluralsight author > > >> > > >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx > France > > > > _______________________________________________ > > 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/20140908/6633f5bf/attachment-0001.html From issues at jboss.org Mon Sep 8 07:35:03 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 8 Sep 2014 07:35:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999829#comment-12999829 ] Martin Kouba commented on CDI-4: -------------------------------- Actually, +javax.annotation.Priority+ is not part of the Java SE (only EE 7+), so it shouldn't be a big problem. > Need a way to provide ordering for Event observers > -------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: 2.0 (discussion) > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 07:36:05 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 8 Sep 2014 07:36:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999829#comment-12999829 ] Martin Kouba edited comment on CDI-4 at 9/8/14 7:35 AM: -------------------------------------------------------- Actually, {{javax.annotation.Priority}} is not a part of the Java SE (only EE 7+), so it shouldn't be a big problem. was (Author: mkouba): Actually, +javax.annotation.Priority+ is not part of the Java SE (only EE 7+), so it shouldn't be a big problem. > Need a way to provide ordering for Event observers > -------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: 2.0 (discussion) > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 08:05:00 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Mon, 8 Sep 2014 08:05:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-459) Clarify whether CDI should validate beans that are not enabled In-Reply-To: References: Message-ID: Jozef Hartinger created CDI-459: ----------------------------------- Summary: Clarify whether CDI should validate beans that are not enabled Key: CDI-459 URL: https://issues.jboss.org/browse/CDI-459 Project: CDI Specification Issues Issue Type: Clarification Components: Beans Affects Versions: 1.2.Final Reporter: Jozef Hartinger CDITCK-438 opens up an interesting question. Should CDI validate beans that are not enabled? First, we need to make a distinction between a *definition error* (e.g. a field that is annotated with both {{@Inject}} and {{@Producer}} ) and a *deployment problem* (e.g. an unsatisfied dependency). The spec currently explicitly requires deployment problems to be detected on enabled beans only: {quote}The container must validate all injection points of all *enabled beans*, all observer methods, all disposer methods and all other Java EE component classes supporting injection when the application is initialized to ensure that there are no unsatisfied or unresolvable ambiguous dependencies. {quote} However, It is not explicitly defined for definition errors, e.g: {quote} If a Bean instance with qualifier @Intercepted is injected into a bean instance other than an interceptor instance, the container automatically detects the problem and treats it as a definition error. {quote} does not say anything about enablement of the bean. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antonio.goncalves at gmail.com Mon Sep 8 09:31:46 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 8 Sep 2014 15:31:46 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: It's just a matter of knowing what we want to do : * Add configuration into CDI 2.0 : it goes into the spec * Forget about configuration : it goes nowhere * Give configuration a chance for later : start the brainstorming, define an API, make sure it works with CDI 2.0... and leave the work in the appendix so the Java EE 9 expert group can read it and decide if they should take it or not. Appendixe is just a way of saying "we've deeply thought about it, this is the way we think it should be done, now the future EG decides" Antonio On Mon, Sep 8, 2014 at 11:51 AM, Romain Manni-Bucau wrote: > @Antonio: -1 for an appendix, bean validation is the example it is > broken. Idea is awesome, everybody liked it so it was added -> great. > Here everybody already agrees it is good so no need of "staging" phase > IMHO. BV appendix was not the API used so it broke apps using it. SO > using proprietary stuff is the same, it basically mean an appendix > spec for something not under discussion (regarding its need) is IMHO > useless. > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > 2014-09-08 10:29 GMT+02:00 Werner Keil : > > Hi, > > > > If it's not really usable as API or annotation I don't see much value in > > adding some "how to" or intent for the future into the Spec Document. > > > > If it was to become a part of CDI 2, there's nothing against optionality > > like MEEP 8 or JSR 363 already practice on the SE/EE side either. > > > > Agorava/DeltaSpike demonstrate how true modularity work, similar to the > JSRs > > mentioned above, where you have multiple module JARs/bundles instead of a > > big monolithic one. Some JSRs like Batch also declared separate > "annotation" > > modules, so that's what CDI 2 should also do if it was a feature Inside > of > > it. > > Calling some features optional if they're not used by every > implementation > > allows them to chose. That was also the main value of keeping @Inject a > > separate "module" under CDI. It was never included into a JDK but used > > independently. > > > > The core of a Config module would ideally work in SE, but CDI 2 already > > declared an aim to have some modules work under SE. > > > > Werner > > > > Am 08.09.2014 09:47 schrieb "Antonio Goncalves" > > : > > > >> Hi all, > >> > >> I really have some concerns about adding configuration into CDI but I > can > >> see benefits too. And what about adding it... and not adding it at the > same > >> time ? In Bean Validation 1.0, the Expert Group decided not to include > >> method-level validation in the spec (it was included in 1.1). But what > they > >> did is to add it as a proposal in the Appendix. > >> > >> If we feel some configuration should get in, why not have a proposal in > >> the Appendix of CDI 2.0 ? It could then be implemented by Weld (and > >> OpenWebBeans if they feel like it). And then, if it's successful and > things > >> get easier, get its own JSR for Java EE 9. > >> > >> WDYT ? > >> > >> Antonio > >> > >> On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau < > rmannibucau at gmail.com> > >> wrote: > >>> > >>> Hmm > >>> > >>> I see config jsr as a jse spec which would allow EE injections in > config > >>> components in EE containers (exactly like jbatch). > >>> > >>> This way it can be used without any container or with any container > >>> easily. Only limit will be to not do something cdi/known containers > will not > >>> support I think. > >>> > >>> Not sure EE side is needed today, a lot can already be done without it > >>> and it can be enhanced later adding some integration words. > >>> > >>> Le 8 sept. 2014 00:01, "Anatole Tresch" a ?crit : > >>> > >>>> Hi Romain > >>>> > >>>> just a few remarks inline... > >>>> > >>>> Summarizing > >>>> 1) injection of values, reinjection, feedback on config changes can > all > >>>> be done with already existing features (producers, extensions). > >>>> 2) configuring/bootstrapping CDI itself, e.g. configuration, is > targeted > >>>> with CDI 2.0 (see spec failing) > >>>> > >>>> So basically we could try to look if there is enough interest to > >>>> standardize configuration in a more general way. For deployment > aspects we > >>>> need an EE JSR, for the rest, another SE standard may be an option as > >>>> well... tbd... > >>>> > >>>> -Anatole > >>>> > >>>> > >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : > >>>>> > >>>>> well sorry to pop in so late but here are my 2cts > >>>> > >>>> easy ;) > >>>> > >>>>> > >>>>> Config JSR is more about environment config IMHO and putting it in > CDI > >>>>> doesn't make sense since more or more spec works without any other > >>>>> spec - CDI in our case. > >>>> > >>>> CDI even with some config mechanism added would still work > "standalone". > >>>> > >>>> > >>>>> > >>>>> This mean CDI can't be the place but should > >>>>> just be the bridge for config JSR. > >>>> > >>>> As I suggested as well. > >>>> > >>>> > >>>>> > >>>>> Plus CDI config will surely highly > >>>>> be an application config first (beans.xml should be the place then) > >>>> > >>>> Yes, app config, but beware people of writing config into beans.xml. > >>>> That is definitively in most cases not what you want. CDI should not > define, > >>>> where and how config is located and formatted. CDI should provide a > SPI, > >>>> where config providers can publish the configured values, so it can be > >>>> injected wherever needed. E.g. some kind of producer, that can provide > >>>> multiple objects to be injected and can benefit from some kind of > callback > >>>> mechanism would be sufficient... > >>>> > >>>>> > >>>>> then environment config can be done at EE level (saying it has to > >>>>> support placeholders or any pre deployment processing). > >>>> > >>>> Config is much more complex. There is no clear border what is > >>>> environment config or environment dependent and what not. This > depends on > >>>> what kind of application you have deployed. As an example the email > address, > >>>> where you send error messages, can be different depenending on the > >>>> stage/environment, but this is not EE related config entry. Also what > an > >>>> environment is, is not a thing that you can define completely. So I > agree > >>>> not to add this complexities to CDI, I would hide them between some > kind of > >>>> "config provider", as mentioned above. CDI does not need to know if > the > >>>> config provided is environment dependent or not, its just what is > visible at > >>>> a current runtime state... > >>>> > >>>>> > >>>>> If you put something like ProjectStage in CDI it is great but then > you > >>>>> have it in JSF, CDI and finally surely all specs...same as > >>>>> converters... > >>>> > >>>> That was originally the idea, when doing a EE config JSR, but without > >>>> such standard. I agree, CDI is not the place to define them. > >>>> > >>>> > >>>>> > >>>>> Config should really be split in: > >>>>> 1) spec dependent config -> spec.xml > >>>>> 2) *common* config (a bit like javax.annotation) for environment and > >>>>> external configuration -> Config JSR > >>>> > >>>> Not 100% sure, if a get the point here... > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : > >>>>> > >>>>> well sorry to pop in so late but here are my 2cts > >>>>> > >>>>> Config JSR is more about environment config IMHO and putting it in > CDI > >>>>> doesn't make sense since more or more spec works without any other > >>>>> spec - CDI in our case. This mean CDI can't be the place but should > >>>>> just be the bridge for config JSR. Plus CDI config will surely highly > >>>>> be an application config first (beans.xml should be the place then) > >>>>> then environment config can be done at EE level (saying it has to > >>>>> support placeholders or any pre deployment processing). > >>>>> > >>>>> If you put something like ProjectStage in CDI it is great but then > you > >>>>> have it in JSF, CDI and finally surely all specs...same as > >>>>> converters... > >>>>> > >>>>> Config should really be split in: > >>>>> 1) spec dependent config -> spec.xml > >>>>> 2) *common* config (a bit like javax.annotation) for environment and > >>>>> external configuration -> Config JSR > >>>>> > >>>>> wdyt? > >>>>> > >>>>> > >>>>> > >>>>> Romain Manni-Bucau > >>>>> Twitter: @rmannibucau > >>>>> Blog: http://rmannibucau.wordpress.com/ > >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau > >>>>> Github: https://github.com/rmannibucau > >>>>> > >>>>> > >>>>> 2014-09-07 23:39 GMT+02:00 Werner Keil : > >>>>> > Sounds like an argument for a CDI module rather than a separate JSR > >>>>> > then?;-) > >>>>> > > >>>>> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch < > atsticks at gmail.com> > >>>>> > wrote: > >>>>> >> > >>>>> >> I would not worry about CDI regarding licensing. Just the sentence > >>>>> >> was > >>>>> >> that Oracle does not want to have more ALv2 in addition to what is > >>>>> >> already > >>>>> >> there. So as long as we do things within CDI, no worries, I think. > >>>>> >> For new > >>>>> >> EE JSRs nevertheless this is a BIG issue and should be clarified > by > >>>>> >> the EC! > >>>>> >> > >>>>> >> > >>>>> >> 2014-09-07 21:44 GMT+02:00 Werner Keil : > >>>>> >>> > >>>>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec > under > >>>>> >>> ALv2 > >>>>> >>> as a dual-license, this was discussed by EC Members but both JCP > EC > >>>>> >>> and > >>>>> >>> Oracle Legal/PMO seems fine with it, and CDI is already an > >>>>> >>> essential > >>>>> >>> building block to Java EE 6/7, hence used with Glassfish, too. I > >>>>> >>> wasn't > >>>>> >>> involved in these discussions, but given CDI is especially > liberal > >>>>> >>> and fully > >>>>> >>> accepted by JCP formalities and license policies, I don't really > >>>>> >>> see what > >>>>> >>> the problem wss for Anatole's JSR attempt (though I know, both > >>>>> >>> Oracle and > >>>>> >>> other EC Members/companies don't always prefer this kind of > >>>>> >>> licensing...;-) > >>>>> >>> > >>>>> >>> Werner > >>>>> >>> > >>>>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament > >>>>> >>> > >>>>> >>> wrote: > >>>>> >>>> > >>>>> >>>> Ok, this mail has me more concerned than anything. Can you > >>>>> >>>> clarify this > >>>>> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. > >>>>> >>>> > >>>>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch > >>>>> >>>> > >>>>> >>>> wrote: > >>>>> >>>>> > >>>>> >>>>> Hi All > >>>>> >>>>> > >>>>> >>>>> unfortunately things seem quite complicated: > >>>>> >>>>> > >>>>> >>>>> first of all, similarities with Deltaspike are basically not > >>>>> >>>>> accidental. The concepts we developed in Credit Suisse are very > >>>>> >>>>> similar to > >>>>> >>>>> Deltaspike, though Deltaspike was not yet born at that time. > >>>>> >>>>> Fortunately we > >>>>> >>>>> ended up with a similar kind of solution. > >>>>> >>>>> filtering still can be done. My idea is to define some kind of > >>>>> >>>>> "configuration provider", which then is dynamically asked for > >>>>> >>>>> configuration. > >>>>> >>>>> How the provider is internally organized, is completely > >>>>> >>>>> transparent to CDI. > >>>>> >>>>> This enables to have multi-layered, complex config solutions > work > >>>>> >>>>> the same > >>>>> >>>>> (from a view point of CDI) like simple programmatic test > >>>>> >>>>> configurations > >>>>> >>>>> during unit tests. The config provider still can support > >>>>> >>>>> filtering and > >>>>> >>>>> dynamic resolution as commonly used in configuration systems. > >>>>> >>>>> Similarly the > >>>>> >>>>> format is basically also not fixed. Of course, would a > reference > >>>>> >>>>> implementation provide a set of functionalities, but I would > >>>>> >>>>> definitively > >>>>> >>>>> not define the exact configuration mechanism as part of the CDI > >>>>> >>>>> (or even a > >>>>> >>>>> EE config JSR). Another reason, beside complexity and time, is > >>>>> >>>>> the fact that > >>>>> >>>>> different companies handle, store and manage configuration > >>>>> >>>>> differently, so a > >>>>> >>>>> mechanism must be flexible enough to accommodate these, without > >>>>> >>>>> adoption > >>>>> >>>>> rate will be low. Furthermore this flexibility also keeps doors > >>>>> >>>>> open for use > >>>>> >>>>> cases we do not know yet. > >>>>> >>>>> Also we have to separate some basically two types of > >>>>> >>>>> configuration > >>>>> >>>>> aspects: > >>>>> >>>>> > >>>>> >>>>> application config basically is injected into deployed > >>>>> >>>>> components, but > >>>>> >>>>> basically only can affect deployment to the extend it can be > >>>>> >>>>> managed and > >>>>> >>>>> injected by CDI. The basic architecture and design, how > >>>>> >>>>> application servers > >>>>> >>>>> to load and deploy are basically not affected. This type of > >>>>> >>>>> configuration > >>>>> >>>>> (mechanism) I see also as a possible addition to CDI, if we > >>>>> >>>>> really fail to > >>>>> >>>>> do something in another JSR. With CDI going for a more modular > >>>>> >>>>> design, even > >>>>> >>>>> basic configuration of CDI can be possible, given we have some > >>>>> >>>>> kind of API, > >>>>> >>>>> we can access during CDI initialization. > >>>>> >>>>> On the other side deployment configuration affects directly how > >>>>> >>>>> the > >>>>> >>>>> application server deploys the application. Configuration here > >>>>> >>>>> would allow > >>>>> >>>>> to define datasources, EJBs, transactional aspects, security, > >>>>> >>>>> persistence, > >>>>> >>>>> war and ear configurations etc. Basically everything you do as > of > >>>>> >>>>> today with > >>>>> >>>>> some kind of XML file, or annotation. Hereby enabling more > >>>>> >>>>> flexibility into > >>>>> >>>>> the existing descriptors is relatively easy, but as mentioned > by > >>>>> >>>>> Mark, > >>>>> >>>>> constraint. Adding more flexibility raises other subtle > problems. > >>>>> >>>>> Imagine a > >>>>> >>>>> application module, e.g. a war, that defines everything it > >>>>> >>>>> requires. There > >>>>> >>>>> is no need to configure anything more on server side (with > spring > >>>>> >>>>> you can do > >>>>> >>>>> this, with Java EE unfortunately not). But this has a severe > >>>>> >>>>> consequence, it > >>>>> >>>>> would make the application really portable in the sense, that > it > >>>>> >>>>> can be > >>>>> >>>>> moved between different app servers (vendors) without any > change > >>>>> >>>>> (ideally). > >>>>> >>>>> As a result commercial profits of some vendor companies may be > >>>>> >>>>> affected. I > >>>>> >>>>> think this is actually one of the key points, why things are > >>>>> >>>>> getting so > >>>>> >>>>> complicated in that area. > >>>>> >>>>> > >>>>> >>>>> Legal aspects also were discussed. One of them is a possible > >>>>> >>>>> legal > >>>>> >>>>> clash of ALv2 with GPL. This is the case already within > >>>>> >>>>> Glassfish, but one > >>>>> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal > >>>>> >>>>> department. At > >>>>> >>>>> the end we decided to use a BSD model. Even dual licensing > >>>>> >>>>> BSD/ALv2 could > >>>>> >>>>> theoretically be an option. If you would choose ALv2, Oracle > will > >>>>> >>>>> not > >>>>> >>>>> include your RI into Glassfish, which is the RI for the EE > >>>>> >>>>> Umbrella JSR, > >>>>> >>>>> meaning your JSR will not be included into EE8. So what should > we > >>>>> >>>>> do? I > >>>>> >>>>> don't have a good answer... > >>>>> >>>>> > >>>>> >>>>> So, I like to discuss configuration aspects here. Nevertheless > if > >>>>> >>>>> we > >>>>> >>>>> decide to add config aspects, be aware that we might only > >>>>> >>>>> (mainly) support > >>>>> >>>>> application config, since everything else directly would impact > >>>>> >>>>> other JSRs. > >>>>> >>>>> And that is obviously quite similar to what Apache Deltaspike > is > >>>>> >>>>> all about > >>>>> >>>>> ;-) > >>>>> >>>>> > >>>>> >>>>> Cheers, > >>>>> >>>>> Anatole > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : > >>>>> >>>>>> > >>>>> >>>>>> Yes, the config group also was (obviously) looking at > >>>>> >>>>>> DeltaSpikes > >>>>> >>>>>> config mechanism as well. > >>>>> >>>>>> There were others who wanted to go more into the 'filtering' > >>>>> >>>>>> approach > >>>>> >>>>>> as done on WebLogic servers (though not sure who else does > that > >>>>> >>>>>> as well). > >>>>> >>>>>> You know, having all the XML configs like WEB-INF/web.xml > >>>>> >>>>>> containing > >>>>> >>>>>> placeholders and the real values only get placed in there at > >>>>> >>>>>> deployment > >>>>> >>>>>> time. I personally find this approach a bit limited from a > >>>>> >>>>>> technical > >>>>> >>>>>> perspective and it already didn't work out for me when using > >>>>> >>>>>> WebLogic (what > >>>>> >>>>>> about changing a configured value after the deployment was > done? > >>>>> >>>>>> What about > >>>>> >>>>>> security? Having passwords in web.xml, unit testing, ...). > >>>>> >>>>>> There are of course also other approaches which all might have > >>>>> >>>>>> strong > >>>>> >>>>>> sides and would have needed to get discussed. > >>>>> >>>>>> > >>>>> >>>>>> But utterly the problem seems to have been legal reasons. We > >>>>> >>>>>> even > >>>>> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF > >>>>> >>>>>> project with > >>>>> >>>>>> substantial support and participation from the JBoss, > DeltaSpike > >>>>> >>>>>> and TomEE > >>>>> >>>>>> communities. > >>>>> >>>>>> > >>>>> >>>>>> Anyway, the time will come when we will resurrect this effort. > >>>>> >>>>>> > >>>>> >>>>>> LieGrue, > >>>>> >>>>>> strub > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> Yep, it contains a simple but extendable notion of > ProjectStage, > >>>>> >>>>>> too;-) > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament > >>>>> >>>>>> > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> Anatole, > >>>>> >>>>>> > >>>>> >>>>>> I'm wondering if some of your configuration description falls > >>>>> >>>>>> under > >>>>> >>>>>> what was put together in DeltaSpike? > >>>>> >>>>>> > >>>>> >>>>>> http://deltaspike.apache.org/configuration.html > >>>>> >>>>>> > >>>>> >>>>>> John > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch > >>>>> >>>>>> > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> Staging is not a question of xml or not xml (the "format" of > >>>>> >>>>>> config). > >>>>> >>>>>> You can do staged config also using xml, or based on a > database > >>>>> >>>>>> or json > >>>>> >>>>>> config service. Staging as well as, more generally speaking, > >>>>> >>>>>> environment > >>>>> >>>>>> dependent config is more like to select/filter the right > config > >>>>> >>>>>> that targets > >>>>> >>>>>> the current (runtime) environment. This might include stages, > >>>>> >>>>>> but also many > >>>>> >>>>>> other aspects are feasible and common (server, tier, ear, war, > >>>>> >>>>>> tenant ...). > >>>>> >>>>>> Since these aspects are per se very complex, it might be > >>>>> >>>>>> advisable to leave > >>>>> >>>>>> them out of any spec (even a dedicated config JSR would > probably > >>>>> >>>>>> not be > >>>>> >>>>>> capable of covering these within the relatively short EE > >>>>> >>>>>> timeframe)... > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil >: > >>>>> >>>>>> > >>>>> >>>>>> Jens/all, > >>>>> >>>>>> > >>>>> >>>>>> A sort of "staging" already was possible using CDI earlier, > see > >>>>> >>>>>> examples like this: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war > >>>>> >>>>>> > >>>>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond > the > >>>>> >>>>>> primitive, hard-coded JSF enum. > >>>>> >>>>>> > >>>>> >>>>>> If that works without XML, while still allowing flexible > >>>>> >>>>>> configuration > >>>>> >>>>>> for different stages or to add and "inject" additional stages > >>>>> >>>>>> maybe even on > >>>>> >>>>>> a tenant basis (for Cloud scenarios) I could see something > like > >>>>> >>>>>> that work > >>>>> >>>>>> without XML. In the Multiconf project we managed to code > >>>>> >>>>>> everything in > >>>>> >>>>>> Python, and similar to Puppet or Chef you can configure and > >>>>> >>>>>> deploy multiple > >>>>> >>>>>> environments with it, Java EE, Spring or Play! several of them > >>>>> >>>>>> are > >>>>> >>>>>> configured this way and it requires no XML (where the > container > >>>>> >>>>>> needs such > >>>>> >>>>>> files, the framework generates them;-) > >>>>> >>>>>> > >>>>> >>>>>> Werner > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, > >>>>> >>>>>> > >>>>> >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole > >>>>> >>>>>> Tresch) > >>>>> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) > >>>>> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() > definition > >>>>> >>>>>> (Anatole Tresch (JIRA)) > >>>>> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) > >>>>> >>>>>> > >>>>> >>>>>> ------------------------------ > >>>>> >>>>>> > >>>>> >>>>>> Message: 4 > >>>>> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 > >>>>> >>>>>> From: Jens Schumann > >>>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... > >>>>> >>>>>> To: Anatole Tresch , Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> Cc: cdi-dev > >>>>> >>>>>> Message-ID: > >>>>> >>>>>> Content-Type: text/plain; charset="windows-1252" > >>>>> >>>>>> > >>>>> >>>>>> I can confirm that this approach works very well. We are > using a > >>>>> >>>>>> similar approach a couple of years now, and I love the > >>>>> >>>>>> simplicity that comes > >>>>> >>>>>> with portable extensions and @Producer methods. See our public > >>>>> >>>>>> version here > >>>>> >>>>>> [1] (works since early CDI 1.0 days) . > >>>>> >>>>>> > >>>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier > >>>>> >>>>>> @Property. > >>>>> >>>>>> We support default values and type conversation for primitives > >>>>> >>>>>> and > >>>>> >>>>>> everything that has a string based constructor. The property > >>>>> >>>>>> source can be > >>>>> >>>>>> anything, from property files (default) to databases or xml > >>>>> >>>>>> files. For > >>>>> >>>>>> examples see tests here [2]. > >>>>> >>>>>> > >>>>> >>>>>> Nevertheless I am not sure if this should be part of an future > >>>>> >>>>>> CDI > >>>>> >>>>>> spec. My concerns include the bloat argument, of course. But > the > >>>>> >>>>>> main reason > >>>>> >>>>>> relates to the fact that we have almost everything in the > >>>>> >>>>>> current CDI spec > >>>>> >>>>>> already. > >>>>> >>>>>> > >>>>> >>>>>> Right now I am quite happy with an custom portable extension > >>>>> >>>>>> that does > >>>>> >>>>>> everything for me. At the time we implemented the extension we > >>>>> >>>>>> realised that > >>>>> >>>>>> the "hard part" was writing an extension that links a > qualified > >>>>> >>>>>> "optional > >>>>> >>>>>> injection point" with an @Producer method while supporting > code > >>>>> >>>>>> based > >>>>> >>>>>> default values. Luckily I had Arne in my team who did that > >>>>> >>>>>> within a few > >>>>> >>>>>> minutes. > >>>>> >>>>>> > >>>>> >>>>>> Because of this experience I would propose that we simplify > >>>>> >>>>>> extension > >>>>> >>>>>> development such that "optional injection points" may be > linked > >>>>> >>>>>> to @Produces > >>>>> >>>>>> values easily. Additionally we have to solve a few more > >>>>> >>>>>> integration issues > >>>>> >>>>>> (e.g. read-only DB access should be available during CDI > >>>>> >>>>>> startup). > >>>>> >>>>>> Everything else should be provided by portable extensions > (e.g. > >>>>> >>>>>> via > >>>>> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. > >>>>> >>>>>> > >>>>> >>>>>> Jens > >>>>> >>>>>> [1] > >>>>> >>>>>> > >>>>> >>>>>> > https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property > >>>>> >>>>>> [2] > >>>>> >>>>>> > >>>>> >>>>>> > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property > >>>>> >>>>>> > >>>>> >>>>>> Von: Anatole Tresch > >>>>> >>>>>> > > >>>>> >>>>>> Datum: Friday 5 September 2014 21:22 > >>>>> >>>>>> An: Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> antonio.goncalves at gmail.com>> > >>>>> >>>>>> Cc: CDI-Dev > >>>>> >>>>>> > > >>>>> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... > >>>>> >>>>>> > >>>>> >>>>>> Hi all, > >>>>> >>>>>> > >>>>> >>>>>> I would not like to add an XML "bloated" mechanism as part of > >>>>> >>>>>> CDI 2.0. > >>>>> >>>>>> Spontaneously I would propose a more CDI like things like: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> * Adding a @Configured annotation (basically a qualifier). > >>>>> >>>>>> This > >>>>> >>>>>> can be in addition to @Inject and would allow to inject > >>>>> >>>>>> "configured" values. > >>>>> >>>>>> * Since configuration can change we may think of a (CDI) > >>>>> >>>>>> event/reinject mechanism based on config changes. By default, > >>>>> >>>>>> this is > >>>>> >>>>>> switched off and we can discuss how it would be activated, > e.g. > >>>>> >>>>>> by an > >>>>> >>>>>> additional flag settable with the @Configured annotation, or > an > >>>>> >>>>>> additional > >>>>> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon > >>>>> >>>>>> framework), or both. > >>>>> >>>>>> * Hereby configured values theoretically behave similar as > >>>>> >>>>>> all > >>>>> >>>>>> other injection points. They also can be qualified (the aspect > >>>>> >>>>>> of scopes, I > >>>>> >>>>>> did not yet have time to think about). The only difference is, > >>>>> >>>>>> that they are > >>>>> >>>>>> satisified using the configuration "system". > >>>>> >>>>>> * The configuration "source" itself could in the extreme > >>>>> >>>>>> simplest > >>>>> >>>>>> way be a Provider>. The CDI spec should not > >>>>> >>>>>> care about > >>>>> >>>>>> how this map is provided (XML, DB, overrides, etc). This still > >>>>> >>>>>> can be > >>>>> >>>>>> standardized later. As long as the ConfigurationSource SPI is > >>>>> >>>>>> defined, > >>>>> >>>>>> companies still can hook in the logic and level of > configuration > >>>>> >>>>>> abstraction > >>>>> >>>>>> they need. > >>>>> >>>>>> * Of course, since not only Strings can be injected, we > need > >>>>> >>>>>> some > >>>>> >>>>>> conversion or adapter logic as basically outlined in my blog. > >>>>> >>>>>> Also here we > >>>>> >>>>>> can add a simple SPI and let the details to the RI. > >>>>> >>>>>> > >>>>> >>>>>> Summarizing a > >>>>> >>>>>> > >>>>> >>>>>> * @Configured annotation > >>>>> >>>>>> * some kind of change event > >>>>> >>>>>> * a ConfigurationSource extends > Provider> > >>>>> >>>>>> * a conversion mechanism from String to T. > >>>>> >>>>>> > >>>>> >>>>>> we get a full fledged configuration mechanism that leverages > >>>>> >>>>>> CDI. > >>>>> >>>>>> > >>>>> >>>>>> That would be my idea basically. WDYT? I will try to work that > >>>>> >>>>>> out in > >>>>> >>>>>> more details. Basically it should be implementable even with > the > >>>>> >>>>>> CDI > >>>>> >>>>>> mechanism already in place with CDI 1.1. > >>>>> >>>>>> > >>>>> >>>>>> Best, > >>>>> >>>>>> Anatole > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> antonio.goncalves at gmail.com>>: > >>>>> >>>>>> One wise man* once said "EJB was a hype specification, we > added > >>>>> >>>>>> too > >>>>> >>>>>> many things to it, it became bloated. The next hype > >>>>> >>>>>> specifications are > >>>>> >>>>>> JAX-RS and CDI, careful with them" > >>>>> >>>>>> > >>>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup > >>>>> >>>>>> being > >>>>> >>>>>> bloated. > >>>>> >>>>>> > >>>>> >>>>>> Antonio > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> *David Blevin > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand > >>>>> >>>>>> > > >>>>> >>>>>> wrote: > >>>>> >>>>>> Hi all, > >>>>> >>>>>> > >>>>> >>>>>> You may have followed the rise and fall of the Java Config JSR > >>>>> >>>>>> > >>>>> >>>>>> ( > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > ). > >>>>> >>>>>> Anatole in CC was leading this initiative and I proposed him > to > >>>>> >>>>>> join > >>>>> >>>>>> us and explore if some part of his late-JSR could be done in > >>>>> >>>>>> CDI. > >>>>> >>>>>> > >>>>> >>>>>> I?m mainly thinking of > https://issues.jboss.org/browse/CDI-123 > >>>>> >>>>>> or > >>>>> >>>>>> related solution. If we achieve to have a majority of specs to > >>>>> >>>>>> integrate > >>>>> >>>>>> with CDI, our configuration solution would therefore become a > >>>>> >>>>>> configuration > >>>>> >>>>>> system for all spec based on CDI 2.0. > >>>>> >>>>>> > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Antonio Goncalves > >>>>> >>>>>> Software architect, Java Champion and Pluralsight author > >>>>> >>>>>> > >>>>> >>>>>> Web site | > >>>>> >>>>>> Twitter | > >>>>> >>>>>> LinkedIn | > >>>>> >>>>>> > >>>>> >>>>>> Pluralsight< > http://pluralsight.com/training/Authors/Details/antonio-goncalves> > >>>>> >>>>>> | Paris JUG | Devoxx > >>>>> >>>>>> France > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Anatole Tresch > >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>>> Gl?rnischweg 10 > >>>>> >>>>>> CH - 8620 Wetzikon > >>>>> >>>>>> > >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>>> Twitter: @atsticks > >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>>> Google: atsticks > >>>>> >>>>>> Mobile +41-76 344 62 79 > >>>>> >>>>>> -------------- next part -------------- > >>>>> >>>>>> An HTML attachment was scrubbed... > >>>>> >>>>>> URL: > >>>>> >>>>>> > >>>>> >>>>>> > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 > >>>>> >>>>>> *************************************** > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Anatole Tresch > >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>>> Gl?rnischweg 10 > >>>>> >>>>>> CH - 8620 Wetzikon > >>>>> >>>>>> > >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>>> Twitter: @atsticks > >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>>> Google: atsticks > >>>>> >>>>>> Mobile +41-76 344 62 79 > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> -- > >>>>> >>>>> Anatole Tresch > >>>>> >>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>> Gl?rnischweg 10 > >>>>> >>>>> CH - 8620 Wetzikon > >>>>> >>>>> > >>>>> >>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>> Twitter: @atsticks > >>>>> >>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>> Google: atsticks > >>>>> >>>>> Mobile +41-76 344 62 79 > >>>>> >>>> > >>>>> >>>> > >>>>> >>> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> -- > >>>>> >> Anatole Tresch > >>>>> >> Java Lead Engineer, JSR Spec Lead > >>>>> >> Gl?rnischweg 10 > >>>>> >> CH - 8620 Wetzikon > >>>>> >> > >>>>> >> Switzerland, Europe Zurich, GMT+1 > >>>>> >> Twitter: @atsticks > >>>>> >> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >> Google: atsticks > >>>>> >> Mobile +41-76 344 62 79 > >>>>> > > >>>>> > > >>>>> > > >>>>> > _______________________________________________ > >>>>> > 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. > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Anatole Tresch > >>>> Java Lead Engineer, JSR Spec Lead > >>>> Gl?rnischweg 10 > >>>> CH - 8620 Wetzikon > >>>> > >>>> Switzerland, Europe Zurich, GMT+1 > >>>> Twitter: @atsticks > >>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>> Google: atsticks > >>>> Mobile +41-76 344 62 79 > >>> > >>> > >>> _______________________________________________ > >>> 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. > >> > >> > >> > >> > >> -- > >> Antonio Goncalves > >> Software architect, Java Champion and Pluralsight author > >> > >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/72a2f08b/attachment-0001.html From issues at jboss.org Mon Sep 8 10:08:02 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 8 Sep 2014 10:08:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999928#comment-12999928 ] Mark Struberg commented on CDI-456: ----------------------------------- jozef, how should that work? The 3 beans are different but have the same beanClass(). So how should this get implemented? let's look at what you quoted. {quote} 5.1.4 For a custom implementation of the Bean interface defined in Section 11.1, ?The Bean interface?, the container calls getBeanClass() to determine the bean class of the bean {quote} So what? Where in this sentence does it state that the 'bean class of the bean' cannot be null? It neither does define what the 'bean class of the bean' is used for by the container. {quote} 5.1.1.2 For a custom implementation of the Bean interface defined in Section 11.1, ?The Bean interface?, the container calls .. getBeanClass() and getStereotypes() to determine whether an alternative is selected in a certain bean archive. {quote} oh fine, but this is not about Alternatives! Show me one single line where you read that getBeanClass() must not be null for any custom bean. This is just missing from the spec and we should clarify what should happen in this case. > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antoine at sabot-durand.net Mon Sep 8 10:09:45 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 8 Sep 2014 16:09:45 +0200 Subject: [cdi-dev] Enhancement proposition to JSR 330 In-Reply-To: References: Message-ID: <909BE9D6-14A3-4AC5-88DE-935EC563B8C3@sabot-durand.net> Werner, Java EE 8 target is JDK 8 as we said before. But te goal of this document is not to discuss with Bob and Juergen how they should use JDK 8 within their spec, but to see if are willing to discuss our suggestion. When we?ll find a general agreement it will be useful to go into such details. Antoine > Le 8 sept. 2014 ? 12:20, Werner Keil a ?crit : > > Antoine/all, > > Thanks for sharing. I also had a discussion (in his own Spring blog) with J?rgen mainly about modularity, and the JDK minimum requirements for Spring 4.x. He confirmed, the "core" components of Spring 4.1 still run under as low as Java 6, while some modules that can be dynamically (Spring-DM aka OSGi;-) added may directly refer to Java 8, in which case you must run SE 8 or higher. > > So while for Java 6/7 or below version of @Inject.next this: > > public interface Provider extends Iterable { > /** > * Provides a fully-constructed and injected instance of {@code T}. > */ > T get(); > [...] > > looks fine, it seemed more than consequent, if you did > > public interface Provider extends Iterable, Supplier { > [...] > > in a Java 8+ case;-) > > Even without looking at Lambdas here in greater detail, it reused what Java SE 8 introduced. > > Again, that is something you, Bob, J?rgen and maybe the EE 8 Spec Leads should discuss, what the reasonable minimum requirements for @Inject.next are, if it's SE 8 or a lower version, though those of course may always stick with the previous ones... > > Werner > > On Mon, Sep 8, 2014 at 12:06 PM, > 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. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition > (Romain Manni-Bucau (JIRA)) > 2. Enhancement proposition to JSR 330 (Antoine Sabot-Durand) > 3. Re: With the end of Java Config... (Werner Keil) > > > ---------------------------------------------------------------------- > > Message: 2 > Date: Mon, 8 Sep 2014 12:03:36 +0200 > From: Antoine Sabot-Durand > > Subject: [cdi-dev] Enhancement proposition to JSR 330 > To: cdi-dev > > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > Hi all, > > > I received an answer from Bob Lee (off list). He likes te idea of us providing a proposal document. So I worked on it this WE. > Here it is : https://docs.google.com/document/d/1KCzqodA8uzXED5DJrEUyl0x3dOUB5mBwL4KcV8xUY_w/edit?usp=sharing > > > Your comments and proposal are most welcome. I propose we discuss this point during our next meeting, and if we agree on the final content send it asap to have Bob and Juergen feeling about these suggestion. > > > Antoine > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/607a6499/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 46, Issue 42 > *************************************** > > _______________________________________________ > 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/20140908/8f6c1acd/attachment.html From antoine at sabot-durand.net Mon Sep 8 10:11:09 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 8 Sep 2014 16:11:09 +0200 Subject: [cdi-dev] Enhancement proposition to JSR 330 In-Reply-To: References: Message-ID: Forgot to say that the doc is currently in read only for anonymous. If you want right to comment it just ask thru Google Drive interface or by sending me your google id in MP. > Le 8 sept. 2014 ? 12:03, Antoine Sabot-Durand a ?crit : > > Hi all, > > > I received an answer from Bob Lee (off list). He likes te idea of us providing a proposal document. So I worked on it this WE. > Here it is : https://docs.google.com/document/d/1KCzqodA8uzXED5DJrEUyl0x3dOUB5mBwL4KcV8xUY_w/edit?usp=sharing > > Your comments and proposal are most welcome. I propose we discuss this point during our next meeting, and if we agree on the final content send it asap to have Bob and Juergen feeling about these suggestion. > > > Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/d97cb49d/attachment-0001.html From issues at jboss.org Mon Sep 8 10:31:01 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Mon, 8 Sep 2014 10:31:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999945#comment-12999945 ] Jozef Hartinger commented on CDI-456: ------------------------------------- {quote}jozef, how should that work? The 3 beans are different but have the same beanClass(). So how should this get implemented?{quote} Look at the example again. They do not have the same bean class. If they had the same bean class then that would be a bug. {quote} So what? Where in this sentence does it state that the 'bean class of the bean' cannot be null? It neither does define what the 'bean class of the bean' is used for by the container. oh fine, but this is not about Alternatives! Show me one single line where you read that getBeanClass() must not be null for any custom bean. This is just missing from the spec and we should clarify what should happen in this case. {quote} Very weird logic you are using here. {{BeanManager.fireEvent()}} does not specify that you cannot pass null, either. Yet, we can probably agree that calling {{BeanManager.fireEvent(null)}} is a stupid thing to do. Here, the spec clearly says that for a custom bean, CDI will call getBeanClass() to infer several pieces of information about the bean yet you feel that returning null is alright? > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antoine at sabot-durand.net Mon Sep 8 10:44:55 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 8 Sep 2014 16:44:55 +0200 Subject: [cdi-dev] General rule for mailing list Message-ID: Hi all, With the beginning of CDI 2.0 we have a lot of exchange on the ML. That?s great and I hope it will continue like this. But to avoid confusion and loosing information, please don?t be afraid to create a new thread when you want to talk about something related to current thread. It will be easier to search in the ML and will save time for all of us. Should you need to look for information in the ML history, you could reach a searchable archive on Nabble : http://cdi-specification-mailing-list.26218.n7.nabble.com/ Thank you Antoine From rmannibucau at gmail.com Mon Sep 8 11:07:01 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 8 Sep 2014 17:07:01 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: like the last one but do you think CDI will get time for it + is it really the place? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-09-08 15:31 GMT+02:00 Antonio Goncalves : > It's just a matter of knowing what we want to do : > > * Add configuration into CDI 2.0 : it goes into the spec > * Forget about configuration : it goes nowhere > * Give configuration a chance for later : start the brainstorming, define an > API, make sure it works with CDI 2.0... and leave the work in the appendix > so the Java EE 9 expert group can read it and decide if they should take it > or not. Appendixe is just a way of saying "we've deeply thought about it, > this is the way we think it should be done, now the future EG decides" > > Antonio > > On Mon, Sep 8, 2014 at 11:51 AM, Romain Manni-Bucau > wrote: >> >> @Antonio: -1 for an appendix, bean validation is the example it is >> broken. Idea is awesome, everybody liked it so it was added -> great. >> Here everybody already agrees it is good so no need of "staging" phase >> IMHO. BV appendix was not the API used so it broke apps using it. SO >> using proprietary stuff is the same, it basically mean an appendix >> spec for something not under discussion (regarding its need) is IMHO >> useless. >> >> >> Romain Manni-Bucau >> Twitter: @rmannibucau >> Blog: http://rmannibucau.wordpress.com/ >> LinkedIn: http://fr.linkedin.com/in/rmannibucau >> Github: https://github.com/rmannibucau >> >> >> 2014-09-08 10:29 GMT+02:00 Werner Keil : >> > Hi, >> > >> > If it's not really usable as API or annotation I don't see much value in >> > adding some "how to" or intent for the future into the Spec Document. >> > >> > If it was to become a part of CDI 2, there's nothing against optionality >> > like MEEP 8 or JSR 363 already practice on the SE/EE side either. >> > >> > Agorava/DeltaSpike demonstrate how true modularity work, similar to the >> > JSRs >> > mentioned above, where you have multiple module JARs/bundles instead of >> > a >> > big monolithic one. Some JSRs like Batch also declared separate >> > "annotation" >> > modules, so that's what CDI 2 should also do if it was a feature Inside >> > of >> > it. >> > Calling some features optional if they're not used by every >> > implementation >> > allows them to chose. That was also the main value of keeping @Inject a >> > separate "module" under CDI. It was never included into a JDK but used >> > independently. >> > >> > The core of a Config module would ideally work in SE, but CDI 2 already >> > declared an aim to have some modules work under SE. >> > >> > Werner >> > >> > Am 08.09.2014 09:47 schrieb "Antonio Goncalves" >> > : >> > >> >> Hi all, >> >> >> >> I really have some concerns about adding configuration into CDI but I >> >> can >> >> see benefits too. And what about adding it... and not adding it at the >> >> same >> >> time ? In Bean Validation 1.0, the Expert Group decided not to include >> >> method-level validation in the spec (it was included in 1.1). But what >> >> they >> >> did is to add it as a proposal in the Appendix. >> >> >> >> If we feel some configuration should get in, why not have a proposal in >> >> the Appendix of CDI 2.0 ? It could then be implemented by Weld (and >> >> OpenWebBeans if they feel like it). And then, if it's successful and >> >> things >> >> get easier, get its own JSR for Java EE 9. >> >> >> >> WDYT ? >> >> >> >> Antonio >> >> >> >> On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau >> >> >> >> wrote: >> >>> >> >>> Hmm >> >>> >> >>> I see config jsr as a jse spec which would allow EE injections in >> >>> config >> >>> components in EE containers (exactly like jbatch). >> >>> >> >>> This way it can be used without any container or with any container >> >>> easily. Only limit will be to not do something cdi/known containers >> >>> will not >> >>> support I think. >> >>> >> >>> Not sure EE side is needed today, a lot can already be done without it >> >>> and it can be enhanced later adding some integration words. >> >>> >> >>> Le 8 sept. 2014 00:01, "Anatole Tresch" a ?crit : >> >>> >> >>>> Hi Romain >> >>>> >> >>>> just a few remarks inline... >> >>>> >> >>>> Summarizing >> >>>> 1) injection of values, reinjection, feedback on config changes can >> >>>> all >> >>>> be done with already existing features (producers, extensions). >> >>>> 2) configuring/bootstrapping CDI itself, e.g. configuration, is >> >>>> targeted >> >>>> with CDI 2.0 (see spec failing) >> >>>> >> >>>> So basically we could try to look if there is enough interest to >> >>>> standardize configuration in a more general way. For deployment >> >>>> aspects we >> >>>> need an EE JSR, for the rest, another SE standard may be an option as >> >>>> well... tbd... >> >>>> >> >>>> -Anatole >> >>>> >> >>>> >> >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : >> >>>>> >> >>>>> well sorry to pop in so late but here are my 2cts >> >>>> >> >>>> easy ;) >> >>>> >> >>>>> >> >>>>> Config JSR is more about environment config IMHO and putting it in >> >>>>> CDI >> >>>>> doesn't make sense since more or more spec works without any other >> >>>>> spec - CDI in our case. >> >>>> >> >>>> CDI even with some config mechanism added would still work >> >>>> "standalone". >> >>>> >> >>>> >> >>>>> >> >>>>> This mean CDI can't be the place but should >> >>>>> just be the bridge for config JSR. >> >>>> >> >>>> As I suggested as well. >> >>>> >> >>>> >> >>>>> >> >>>>> Plus CDI config will surely highly >> >>>>> be an application config first (beans.xml should be the place then) >> >>>> >> >>>> Yes, app config, but beware people of writing config into beans.xml. >> >>>> That is definitively in most cases not what you want. CDI should not >> >>>> define, >> >>>> where and how config is located and formatted. CDI should provide a >> >>>> SPI, >> >>>> where config providers can publish the configured values, so it can >> >>>> be >> >>>> injected wherever needed. E.g. some kind of producer, that can >> >>>> provide >> >>>> multiple objects to be injected and can benefit from some kind of >> >>>> callback >> >>>> mechanism would be sufficient... >> >>>> >> >>>>> >> >>>>> then environment config can be done at EE level (saying it has to >> >>>>> support placeholders or any pre deployment processing). >> >>>> >> >>>> Config is much more complex. There is no clear border what is >> >>>> environment config or environment dependent and what not. This >> >>>> depends on >> >>>> what kind of application you have deployed. As an example the email >> >>>> address, >> >>>> where you send error messages, can be different depenending on the >> >>>> stage/environment, but this is not EE related config entry. Also what >> >>>> an >> >>>> environment is, is not a thing that you can define completely. So I >> >>>> agree >> >>>> not to add this complexities to CDI, I would hide them between some >> >>>> kind of >> >>>> "config provider", as mentioned above. CDI does not need to know if >> >>>> the >> >>>> config provided is environment dependent or not, its just what is >> >>>> visible at >> >>>> a current runtime state... >> >>>> >> >>>>> >> >>>>> If you put something like ProjectStage in CDI it is great but then >> >>>>> you >> >>>>> have it in JSF, CDI and finally surely all specs...same as >> >>>>> converters... >> >>>> >> >>>> That was originally the idea, when doing a EE config JSR, but without >> >>>> such standard. I agree, CDI is not the place to define them. >> >>>> >> >>>> >> >>>>> >> >>>>> Config should really be split in: >> >>>>> 1) spec dependent config -> spec.xml >> >>>>> 2) *common* config (a bit like javax.annotation) for environment and >> >>>>> external configuration -> Config JSR >> >>>> >> >>>> Not 100% sure, if a get the point here... >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : >> >>>>> >> >>>>> well sorry to pop in so late but here are my 2cts >> >>>>> >> >>>>> Config JSR is more about environment config IMHO and putting it in >> >>>>> CDI >> >>>>> doesn't make sense since more or more spec works without any other >> >>>>> spec - CDI in our case. This mean CDI can't be the place but should >> >>>>> just be the bridge for config JSR. Plus CDI config will surely >> >>>>> highly >> >>>>> be an application config first (beans.xml should be the place then) >> >>>>> then environment config can be done at EE level (saying it has to >> >>>>> support placeholders or any pre deployment processing). >> >>>>> >> >>>>> If you put something like ProjectStage in CDI it is great but then >> >>>>> you >> >>>>> have it in JSF, CDI and finally surely all specs...same as >> >>>>> converters... >> >>>>> >> >>>>> Config should really be split in: >> >>>>> 1) spec dependent config -> spec.xml >> >>>>> 2) *common* config (a bit like javax.annotation) for environment and >> >>>>> external configuration -> Config JSR >> >>>>> >> >>>>> wdyt? >> >>>>> >> >>>>> >> >>>>> >> >>>>> Romain Manni-Bucau >> >>>>> Twitter: @rmannibucau >> >>>>> Blog: http://rmannibucau.wordpress.com/ >> >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >> >>>>> Github: https://github.com/rmannibucau >> >>>>> >> >>>>> >> >>>>> 2014-09-07 23:39 GMT+02:00 Werner Keil : >> >>>>> > Sounds like an argument for a CDI module rather than a separate >> >>>>> > JSR >> >>>>> > then?;-) >> >>>>> > >> >>>>> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch >> >>>>> > >> >>>>> > wrote: >> >>>>> >> >> >>>>> >> I would not worry about CDI regarding licensing. Just the >> >>>>> >> sentence >> >>>>> >> was >> >>>>> >> that Oracle does not want to have more ALv2 in addition to what >> >>>>> >> is >> >>>>> >> already >> >>>>> >> there. So as long as we do things within CDI, no worries, I >> >>>>> >> think. >> >>>>> >> For new >> >>>>> >> EE JSRs nevertheless this is a BIG issue and should be clarified >> >>>>> >> by >> >>>>> >> the EC! >> >>>>> >> >> >>>>> >> >> >>>>> >> 2014-09-07 21:44 GMT+02:00 Werner Keil : >> >>>>> >>> >> >>>>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec >> >>>>> >>> under >> >>>>> >>> ALv2 >> >>>>> >>> as a dual-license, this was discussed by EC Members but both JCP >> >>>>> >>> EC >> >>>>> >>> and >> >>>>> >>> Oracle Legal/PMO seems fine with it, and CDI is already an >> >>>>> >>> essential >> >>>>> >>> building block to Java EE 6/7, hence used with Glassfish, too. I >> >>>>> >>> wasn't >> >>>>> >>> involved in these discussions, but given CDI is especially >> >>>>> >>> liberal >> >>>>> >>> and fully >> >>>>> >>> accepted by JCP formalities and license policies, I don't really >> >>>>> >>> see what >> >>>>> >>> the problem wss for Anatole's JSR attempt (though I know, both >> >>>>> >>> Oracle and >> >>>>> >>> other EC Members/companies don't always prefer this kind of >> >>>>> >>> licensing...;-) >> >>>>> >>> >> >>>>> >>> Werner >> >>>>> >>> >> >>>>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament >> >>>>> >>> >> >>>>> >>> wrote: >> >>>>> >>>> >> >>>>> >>>> Ok, this mail has me more concerned than anything. Can you >> >>>>> >>>> clarify this >> >>>>> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. >> >>>>> >>>> >> >>>>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch >> >>>>> >>>> >> >>>>> >>>> wrote: >> >>>>> >>>>> >> >>>>> >>>>> Hi All >> >>>>> >>>>> >> >>>>> >>>>> unfortunately things seem quite complicated: >> >>>>> >>>>> >> >>>>> >>>>> first of all, similarities with Deltaspike are basically not >> >>>>> >>>>> accidental. The concepts we developed in Credit Suisse are >> >>>>> >>>>> very >> >>>>> >>>>> similar to >> >>>>> >>>>> Deltaspike, though Deltaspike was not yet born at that time. >> >>>>> >>>>> Fortunately we >> >>>>> >>>>> ended up with a similar kind of solution. >> >>>>> >>>>> filtering still can be done. My idea is to define some kind of >> >>>>> >>>>> "configuration provider", which then is dynamically asked for >> >>>>> >>>>> configuration. >> >>>>> >>>>> How the provider is internally organized, is completely >> >>>>> >>>>> transparent to CDI. >> >>>>> >>>>> This enables to have multi-layered, complex config solutions >> >>>>> >>>>> work >> >>>>> >>>>> the same >> >>>>> >>>>> (from a view point of CDI) like simple programmatic test >> >>>>> >>>>> configurations >> >>>>> >>>>> during unit tests. The config provider still can support >> >>>>> >>>>> filtering and >> >>>>> >>>>> dynamic resolution as commonly used in configuration systems. >> >>>>> >>>>> Similarly the >> >>>>> >>>>> format is basically also not fixed. Of course, would a >> >>>>> >>>>> reference >> >>>>> >>>>> implementation provide a set of functionalities, but I would >> >>>>> >>>>> definitively >> >>>>> >>>>> not define the exact configuration mechanism as part of the >> >>>>> >>>>> CDI >> >>>>> >>>>> (or even a >> >>>>> >>>>> EE config JSR). Another reason, beside complexity and time, is >> >>>>> >>>>> the fact that >> >>>>> >>>>> different companies handle, store and manage configuration >> >>>>> >>>>> differently, so a >> >>>>> >>>>> mechanism must be flexible enough to accommodate these, >> >>>>> >>>>> without >> >>>>> >>>>> adoption >> >>>>> >>>>> rate will be low. Furthermore this flexibility also keeps >> >>>>> >>>>> doors >> >>>>> >>>>> open for use >> >>>>> >>>>> cases we do not know yet. >> >>>>> >>>>> Also we have to separate some basically two types of >> >>>>> >>>>> configuration >> >>>>> >>>>> aspects: >> >>>>> >>>>> >> >>>>> >>>>> application config basically is injected into deployed >> >>>>> >>>>> components, but >> >>>>> >>>>> basically only can affect deployment to the extend it can be >> >>>>> >>>>> managed and >> >>>>> >>>>> injected by CDI. The basic architecture and design, how >> >>>>> >>>>> application servers >> >>>>> >>>>> to load and deploy are basically not affected. This type of >> >>>>> >>>>> configuration >> >>>>> >>>>> (mechanism) I see also as a possible addition to CDI, if we >> >>>>> >>>>> really fail to >> >>>>> >>>>> do something in another JSR. With CDI going for a more modular >> >>>>> >>>>> design, even >> >>>>> >>>>> basic configuration of CDI can be possible, given we have some >> >>>>> >>>>> kind of API, >> >>>>> >>>>> we can access during CDI initialization. >> >>>>> >>>>> On the other side deployment configuration affects directly >> >>>>> >>>>> how >> >>>>> >>>>> the >> >>>>> >>>>> application server deploys the application. Configuration here >> >>>>> >>>>> would allow >> >>>>> >>>>> to define datasources, EJBs, transactional aspects, security, >> >>>>> >>>>> persistence, >> >>>>> >>>>> war and ear configurations etc. Basically everything you do as >> >>>>> >>>>> of >> >>>>> >>>>> today with >> >>>>> >>>>> some kind of XML file, or annotation. Hereby enabling more >> >>>>> >>>>> flexibility into >> >>>>> >>>>> the existing descriptors is relatively easy, but as mentioned >> >>>>> >>>>> by >> >>>>> >>>>> Mark, >> >>>>> >>>>> constraint. Adding more flexibility raises other subtle >> >>>>> >>>>> problems. >> >>>>> >>>>> Imagine a >> >>>>> >>>>> application module, e.g. a war, that defines everything it >> >>>>> >>>>> requires. There >> >>>>> >>>>> is no need to configure anything more on server side (with >> >>>>> >>>>> spring >> >>>>> >>>>> you can do >> >>>>> >>>>> this, with Java EE unfortunately not). But this has a severe >> >>>>> >>>>> consequence, it >> >>>>> >>>>> would make the application really portable in the sense, that >> >>>>> >>>>> it >> >>>>> >>>>> can be >> >>>>> >>>>> moved between different app servers (vendors) without any >> >>>>> >>>>> change >> >>>>> >>>>> (ideally). >> >>>>> >>>>> As a result commercial profits of some vendor companies may be >> >>>>> >>>>> affected. I >> >>>>> >>>>> think this is actually one of the key points, why things are >> >>>>> >>>>> getting so >> >>>>> >>>>> complicated in that area. >> >>>>> >>>>> >> >>>>> >>>>> Legal aspects also were discussed. One of them is a possible >> >>>>> >>>>> legal >> >>>>> >>>>> clash of ALv2 with GPL. This is the case already within >> >>>>> >>>>> Glassfish, but one >> >>>>> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal >> >>>>> >>>>> department. At >> >>>>> >>>>> the end we decided to use a BSD model. Even dual licensing >> >>>>> >>>>> BSD/ALv2 could >> >>>>> >>>>> theoretically be an option. If you would choose ALv2, Oracle >> >>>>> >>>>> will >> >>>>> >>>>> not >> >>>>> >>>>> include your RI into Glassfish, which is the RI for the EE >> >>>>> >>>>> Umbrella JSR, >> >>>>> >>>>> meaning your JSR will not be included into EE8. So what should >> >>>>> >>>>> we >> >>>>> >>>>> do? I >> >>>>> >>>>> don't have a good answer... >> >>>>> >>>>> >> >>>>> >>>>> So, I like to discuss configuration aspects here. Nevertheless >> >>>>> >>>>> if >> >>>>> >>>>> we >> >>>>> >>>>> decide to add config aspects, be aware that we might only >> >>>>> >>>>> (mainly) support >> >>>>> >>>>> application config, since everything else directly would >> >>>>> >>>>> impact >> >>>>> >>>>> other JSRs. >> >>>>> >>>>> And that is obviously quite similar to what Apache Deltaspike >> >>>>> >>>>> is >> >>>>> >>>>> all about >> >>>>> >>>>> ;-) >> >>>>> >>>>> >> >>>>> >>>>> Cheers, >> >>>>> >>>>> Anatole >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : >> >>>>> >>>>>> >> >>>>> >>>>>> Yes, the config group also was (obviously) looking at >> >>>>> >>>>>> DeltaSpikes >> >>>>> >>>>>> config mechanism as well. >> >>>>> >>>>>> There were others who wanted to go more into the 'filtering' >> >>>>> >>>>>> approach >> >>>>> >>>>>> as done on WebLogic servers (though not sure who else does >> >>>>> >>>>>> that >> >>>>> >>>>>> as well). >> >>>>> >>>>>> You know, having all the XML configs like WEB-INF/web.xml >> >>>>> >>>>>> containing >> >>>>> >>>>>> placeholders and the real values only get placed in there at >> >>>>> >>>>>> deployment >> >>>>> >>>>>> time. I personally find this approach a bit limited from a >> >>>>> >>>>>> technical >> >>>>> >>>>>> perspective and it already didn't work out for me when using >> >>>>> >>>>>> WebLogic (what >> >>>>> >>>>>> about changing a configured value after the deployment was >> >>>>> >>>>>> done? >> >>>>> >>>>>> What about >> >>>>> >>>>>> security? Having passwords in web.xml, unit testing, ...). >> >>>>> >>>>>> There are of course also other approaches which all might >> >>>>> >>>>>> have >> >>>>> >>>>>> strong >> >>>>> >>>>>> sides and would have needed to get discussed. >> >>>>> >>>>>> >> >>>>> >>>>>> But utterly the problem seems to have been legal reasons. We >> >>>>> >>>>>> even >> >>>>> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an >> >>>>> >>>>>> ASF >> >>>>> >>>>>> project with >> >>>>> >>>>>> substantial support and participation from the JBoss, >> >>>>> >>>>>> DeltaSpike >> >>>>> >>>>>> and TomEE >> >>>>> >>>>>> communities. >> >>>>> >>>>>> >> >>>>> >>>>>> Anyway, the time will come when we will resurrect this >> >>>>> >>>>>> effort. >> >>>>> >>>>>> >> >>>>> >>>>>> LieGrue, >> >>>>> >>>>>> strub >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil >> >>>>> >>>>>> wrote: >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> Yep, it contains a simple but extendable notion of >> >>>>> >>>>>> ProjectStage, >> >>>>> >>>>>> too;-) >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament >> >>>>> >>>>>> >> >>>>> >>>>>> wrote: >> >>>>> >>>>>> >> >>>>> >>>>>> Anatole, >> >>>>> >>>>>> >> >>>>> >>>>>> I'm wondering if some of your configuration description falls >> >>>>> >>>>>> under >> >>>>> >>>>>> what was put together in DeltaSpike? >> >>>>> >>>>>> >> >>>>> >>>>>> http://deltaspike.apache.org/configuration.html >> >>>>> >>>>>> >> >>>>> >>>>>> John >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch >> >>>>> >>>>>> >> >>>>> >>>>>> wrote: >> >>>>> >>>>>> >> >>>>> >>>>>> Staging is not a question of xml or not xml (the "format" of >> >>>>> >>>>>> config). >> >>>>> >>>>>> You can do staged config also using xml, or based on a >> >>>>> >>>>>> database >> >>>>> >>>>>> or json >> >>>>> >>>>>> config service. Staging as well as, more generally speaking, >> >>>>> >>>>>> environment >> >>>>> >>>>>> dependent config is more like to select/filter the right >> >>>>> >>>>>> config >> >>>>> >>>>>> that targets >> >>>>> >>>>>> the current (runtime) environment. This might include stages, >> >>>>> >>>>>> but also many >> >>>>> >>>>>> other aspects are feasible and common (server, tier, ear, >> >>>>> >>>>>> war, >> >>>>> >>>>>> tenant ...). >> >>>>> >>>>>> Since these aspects are per se very complex, it might be >> >>>>> >>>>>> advisable to leave >> >>>>> >>>>>> them out of any spec (even a dedicated config JSR would >> >>>>> >>>>>> probably >> >>>>> >>>>>> not be >> >>>>> >>>>>> capable of covering these within the relatively short EE >> >>>>> >>>>>> timeframe)... >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil >> >>>>> >>>>>> : >> >>>>> >>>>>> >> >>>>> >>>>>> Jens/all, >> >>>>> >>>>>> >> >>>>> >>>>>> A sort of "staging" already was possible using CDI earlier, >> >>>>> >>>>>> see >> >>>>> >>>>>> examples like this: >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >> >>>>> >>>>>> >> >>>>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond >> >>>>> >>>>>> the >> >>>>> >>>>>> primitive, hard-coded JSF enum. >> >>>>> >>>>>> >> >>>>> >>>>>> If that works without XML, while still allowing flexible >> >>>>> >>>>>> configuration >> >>>>> >>>>>> for different stages or to add and "inject" additional >> >>>>> >>>>>> stages >> >>>>> >>>>>> maybe even on >> >>>>> >>>>>> a tenant basis (for Cloud scenarios) I could see something >> >>>>> >>>>>> like >> >>>>> >>>>>> that work >> >>>>> >>>>>> without XML. In the Multiconf project we managed to code >> >>>>> >>>>>> everything in >> >>>>> >>>>>> Python, and similar to Puppet or Chef you can configure and >> >>>>> >>>>>> deploy multiple >> >>>>> >>>>>> environments with it, Java EE, Spring or Play! several of >> >>>>> >>>>>> them >> >>>>> >>>>>> are >> >>>>> >>>>>> configured this way and it requires no XML (where the >> >>>>> >>>>>> container >> >>>>> >>>>>> needs such >> >>>>> >>>>>> files, the framework generates them;-) >> >>>>> >>>>>> >> >>>>> >>>>>> Werner >> >>>>> >>>>>> >> >>>>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, >> >>>>> >>>>>> >> >>>>> >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github >> >>>>> >>>>>> (Anatole >> >>>>> >>>>>> Tresch) >> >>>>> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >> >>>>> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() >> >>>>> >>>>>> definition >> >>>>> >>>>>> (Anatole Tresch (JIRA)) >> >>>>> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) >> >>>>> >>>>>> >> >>>>> >>>>>> ------------------------------ >> >>>>> >>>>>> >> >>>>> >>>>>> Message: 4 >> >>>>> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >> >>>>> >>>>>> From: Jens Schumann >> >>>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... >> >>>>> >>>>>> To: Anatole Tresch , Antonio Goncalves >> >>>>> >>>>>> >> >>>>> >>>>>> Cc: cdi-dev >> >>>>> >>>>>> Message-ID: >> >>>>> >>>>>> Content-Type: text/plain; charset="windows-1252" >> >>>>> >>>>>> >> >>>>> >>>>>> I can confirm that this approach works very well. We are >> >>>>> >>>>>> using a >> >>>>> >>>>>> similar approach a couple of years now, and I love the >> >>>>> >>>>>> simplicity that comes >> >>>>> >>>>>> with portable extensions and @Producer methods. See our >> >>>>> >>>>>> public >> >>>>> >>>>>> version here >> >>>>> >>>>>> [1] (works since early CDI 1.0 days) . >> >>>>> >>>>>> >> >>>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier >> >>>>> >>>>>> @Property. >> >>>>> >>>>>> We support default values and type conversation for >> >>>>> >>>>>> primitives >> >>>>> >>>>>> and >> >>>>> >>>>>> everything that has a string based constructor. The property >> >>>>> >>>>>> source can be >> >>>>> >>>>>> anything, from property files (default) to databases or xml >> >>>>> >>>>>> files. For >> >>>>> >>>>>> examples see tests here [2]. >> >>>>> >>>>>> >> >>>>> >>>>>> Nevertheless I am not sure if this should be part of an >> >>>>> >>>>>> future >> >>>>> >>>>>> CDI >> >>>>> >>>>>> spec. My concerns include the bloat argument, of course. But >> >>>>> >>>>>> the >> >>>>> >>>>>> main reason >> >>>>> >>>>>> relates to the fact that we have almost everything in the >> >>>>> >>>>>> current CDI spec >> >>>>> >>>>>> already. >> >>>>> >>>>>> >> >>>>> >>>>>> Right now I am quite happy with an custom portable extension >> >>>>> >>>>>> that does >> >>>>> >>>>>> everything for me. At the time we implemented the extension >> >>>>> >>>>>> we >> >>>>> >>>>>> realised that >> >>>>> >>>>>> the "hard part" was writing an extension that links a >> >>>>> >>>>>> qualified >> >>>>> >>>>>> "optional >> >>>>> >>>>>> injection point" with an @Producer method while supporting >> >>>>> >>>>>> code >> >>>>> >>>>>> based >> >>>>> >>>>>> default values. Luckily I had Arne in my team who did that >> >>>>> >>>>>> within a few >> >>>>> >>>>>> minutes. >> >>>>> >>>>>> >> >>>>> >>>>>> Because of this experience I would propose that we simplify >> >>>>> >>>>>> extension >> >>>>> >>>>>> development such that "optional injection points" may be >> >>>>> >>>>>> linked >> >>>>> >>>>>> to @Produces >> >>>>> >>>>>> values easily. Additionally we have to solve a few more >> >>>>> >>>>>> integration issues >> >>>>> >>>>>> (e.g. read-only DB access should be available during CDI >> >>>>> >>>>>> startup). >> >>>>> >>>>>> Everything else should be provided by portable extensions >> >>>>> >>>>>> (e.g. >> >>>>> >>>>>> via >> >>>>> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. >> >>>>> >>>>>> >> >>>>> >>>>>> Jens >> >>>>> >>>>>> [1] >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >> >>>>> >>>>>> [2] >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >> >>>>> >>>>>> >> >>>>> >>>>>> Von: Anatole Tresch >> >>>>> >>>>>> > >> >>>>> >>>>>> Datum: Friday 5 September 2014 21:22 >> >>>>> >>>>>> An: Antonio Goncalves >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> > >> >>>>> >>>>>> Cc: CDI-Dev >> >>>>> >>>>>> > >> >>>>> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... >> >>>>> >>>>>> >> >>>>> >>>>>> Hi all, >> >>>>> >>>>>> >> >>>>> >>>>>> I would not like to add an XML "bloated" mechanism as part of >> >>>>> >>>>>> CDI 2.0. >> >>>>> >>>>>> Spontaneously I would propose a more CDI like things like: >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> * Adding a @Configured annotation (basically a >> >>>>> >>>>>> qualifier). >> >>>>> >>>>>> This >> >>>>> >>>>>> can be in addition to @Inject and would allow to inject >> >>>>> >>>>>> "configured" values. >> >>>>> >>>>>> * Since configuration can change we may think of a (CDI) >> >>>>> >>>>>> event/reinject mechanism based on config changes. By default, >> >>>>> >>>>>> this is >> >>>>> >>>>>> switched off and we can discuss how it would be activated, >> >>>>> >>>>>> e.g. >> >>>>> >>>>>> by an >> >>>>> >>>>>> additional flag settable with the @Configured annotation, or >> >>>>> >>>>>> an >> >>>>> >>>>>> additional >> >>>>> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon >> >>>>> >>>>>> framework), or both. >> >>>>> >>>>>> * Hereby configured values theoretically behave similar >> >>>>> >>>>>> as >> >>>>> >>>>>> all >> >>>>> >>>>>> other injection points. They also can be qualified (the >> >>>>> >>>>>> aspect >> >>>>> >>>>>> of scopes, I >> >>>>> >>>>>> did not yet have time to think about). The only difference >> >>>>> >>>>>> is, >> >>>>> >>>>>> that they are >> >>>>> >>>>>> satisified using the configuration "system". >> >>>>> >>>>>> * The configuration "source" itself could in the extreme >> >>>>> >>>>>> simplest >> >>>>> >>>>>> way be a Provider>. The CDI spec should >> >>>>> >>>>>> not >> >>>>> >>>>>> care about >> >>>>> >>>>>> how this map is provided (XML, DB, overrides, etc). This >> >>>>> >>>>>> still >> >>>>> >>>>>> can be >> >>>>> >>>>>> standardized later. As long as the ConfigurationSource SPI is >> >>>>> >>>>>> defined, >> >>>>> >>>>>> companies still can hook in the logic and level of >> >>>>> >>>>>> configuration >> >>>>> >>>>>> abstraction >> >>>>> >>>>>> they need. >> >>>>> >>>>>> * Of course, since not only Strings can be injected, we >> >>>>> >>>>>> need >> >>>>> >>>>>> some >> >>>>> >>>>>> conversion or adapter logic as basically outlined in my blog. >> >>>>> >>>>>> Also here we >> >>>>> >>>>>> can add a simple SPI and let the details to the RI. >> >>>>> >>>>>> >> >>>>> >>>>>> Summarizing a >> >>>>> >>>>>> >> >>>>> >>>>>> * @Configured annotation >> >>>>> >>>>>> * some kind of change event >> >>>>> >>>>>> * a ConfigurationSource extends >> >>>>> >>>>>> Provider> >> >>>>> >>>>>> * a conversion mechanism from String to T. >> >>>>> >>>>>> >> >>>>> >>>>>> we get a full fledged configuration mechanism that leverages >> >>>>> >>>>>> CDI. >> >>>>> >>>>>> >> >>>>> >>>>>> That would be my idea basically. WDYT? I will try to work >> >>>>> >>>>>> that >> >>>>> >>>>>> out in >> >>>>> >>>>>> more details. Basically it should be implementable even with >> >>>>> >>>>>> the >> >>>>> >>>>>> CDI >> >>>>> >>>>>> mechanism already in place with CDI 1.1. >> >>>>> >>>>>> >> >>>>> >>>>>> Best, >> >>>>> >>>>>> Anatole >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >: >> >>>>> >>>>>> One wise man* once said "EJB was a hype specification, we >> >>>>> >>>>>> added >> >>>>> >>>>>> too >> >>>>> >>>>>> many things to it, it became bloated. The next hype >> >>>>> >>>>>> specifications are >> >>>>> >>>>>> JAX-RS and CDI, careful with them" >> >>>>> >>>>>> >> >>>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup >> >>>>> >>>>>> being >> >>>>> >>>>>> bloated. >> >>>>> >>>>>> >> >>>>> >>>>>> Antonio >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> *David Blevin >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand >> >>>>> >>>>>> > >> >>>>> >>>>>> wrote: >> >>>>> >>>>>> Hi all, >> >>>>> >>>>>> >> >>>>> >>>>>> You may have followed the rise and fall of the Java Config >> >>>>> >>>>>> JSR >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> (http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html). >> >>>>> >>>>>> Anatole in CC was leading this initiative and I proposed him >> >>>>> >>>>>> to >> >>>>> >>>>>> join >> >>>>> >>>>>> us and explore if some part of his late-JSR could be done in >> >>>>> >>>>>> CDI. >> >>>>> >>>>>> >> >>>>> >>>>>> I?m mainly thinking of >> >>>>> >>>>>> https://issues.jboss.org/browse/CDI-123 >> >>>>> >>>>>> or >> >>>>> >>>>>> related solution. If we achieve to have a majority of specs >> >>>>> >>>>>> to >> >>>>> >>>>>> integrate >> >>>>> >>>>>> with CDI, our configuration solution would therefore become a >> >>>>> >>>>>> configuration >> >>>>> >>>>>> system for all spec based on CDI 2.0. >> >>>>> >>>>>> >> >>>>> >>>>>> 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. >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> -- >> >>>>> >>>>>> Antonio Goncalves >> >>>>> >>>>>> Software architect, Java Champion and Pluralsight author >> >>>>> >>>>>> >> >>>>> >>>>>> Web site | >> >>>>> >>>>>> Twitter | >> >>>>> >>>>>> LinkedIn | >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> Pluralsight >> >>>>> >>>>>> | Paris JUG | Devoxx >> >>>>> >>>>>> France >> >>>>> >>>>>> >> >>>>> >>>>>> _______________________________________________ >> >>>>> >>>>>> 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. >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> -- >> >>>>> >>>>>> Anatole Tresch >> >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead >> >>>>> >>>>>> Gl?rnischweg 10 >> >>>>> >>>>>> CH - 8620 Wetzikon >> >>>>> >>>>>> >> >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >> >>>>> >>>>>> Twitter: @atsticks >> >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >> >>>>> >>>>>> Google: atsticks >> >>>>> >>>>>> Mobile +41-76 344 62 79 >> >>>>> >>>>>> -------------- next part -------------- >> >>>>> >>>>>> An HTML attachment was scrubbed... >> >>>>> >>>>>> URL: >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >> >>>>> >>>>>> *************************************** >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> _______________________________________________ >> >>>>> >>>>>> 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. >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> -- >> >>>>> >>>>>> Anatole Tresch >> >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead >> >>>>> >>>>>> Gl?rnischweg 10 >> >>>>> >>>>>> CH - 8620 Wetzikon >> >>>>> >>>>>> >> >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >> >>>>> >>>>>> Twitter: @atsticks >> >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >> >>>>> >>>>>> Google: atsticks >> >>>>> >>>>>> Mobile +41-76 344 62 79 >> >>>>> >>>>>> >> >>>>> >>>>>> _______________________________________________ >> >>>>> >>>>>> 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. >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> _______________________________________________ >> >>>>> >>>>>> 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. >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> -- >> >>>>> >>>>> Anatole Tresch >> >>>>> >>>>> Java Lead Engineer, JSR Spec Lead >> >>>>> >>>>> Gl?rnischweg 10 >> >>>>> >>>>> CH - 8620 Wetzikon >> >>>>> >>>>> >> >>>>> >>>>> Switzerland, Europe Zurich, GMT+1 >> >>>>> >>>>> Twitter: @atsticks >> >>>>> >>>>> Blogs: http://javaremarkables.blogspot.ch/ >> >>>>> >>>>> Google: atsticks >> >>>>> >>>>> Mobile +41-76 344 62 79 >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> -- >> >>>>> >> Anatole Tresch >> >>>>> >> Java Lead Engineer, JSR Spec Lead >> >>>>> >> Gl?rnischweg 10 >> >>>>> >> CH - 8620 Wetzikon >> >>>>> >> >> >>>>> >> Switzerland, Europe Zurich, GMT+1 >> >>>>> >> Twitter: @atsticks >> >>>>> >> Blogs: http://javaremarkables.blogspot.ch/ >> >>>>> >> Google: atsticks >> >>>>> >> Mobile +41-76 344 62 79 >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > _______________________________________________ >> >>>>> > 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. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Anatole Tresch >> >>>> Java Lead Engineer, JSR Spec Lead >> >>>> Gl?rnischweg 10 >> >>>> CH - 8620 Wetzikon >> >>>> >> >>>> Switzerland, Europe Zurich, GMT+1 >> >>>> Twitter: @atsticks >> >>>> Blogs: http://javaremarkables.blogspot.ch/ >> >>>> Google: atsticks >> >>>> Mobile +41-76 344 62 79 >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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. >> >> >> >> >> >> >> >> >> >> -- >> >> Antonio Goncalves >> >> Software architect, Java Champion and Pluralsight author >> >> >> >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France From struberg at yahoo.de Mon Sep 8 11:20:11 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 8 Sep 2014 16:20:11 +0100 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: <1410189611.18901.YahooMailNeo@web28901.mail.ir2.yahoo.com> Antonio, the problem is that the config mechanism would need to be plain old java. In the best case even without classpath scanning. We need it during the boot time of the container (CDI and all other EE components boot time) so we cannot use CDI mechanics. If you look at DeltaSpike you will see that ConfigResolver just uses plain static methods. This is the only way we can use the config mechanism during boot time, e.g. to exclude classes in ProcessAnnotatedType, etc. The CDI part are only a few producers on top of it. We really need some common ground for configuration, but I don't think the CDI spec is the place where it should be handled... LieGrue, strub On Monday, 8 September 2014, 15:32, Antonio Goncalves wrote: > > >It's just a matter of knowing what we want to do : > > >* Add configuration into CDI 2.0 : it goes into the spec >* Forget about configuration : it goes nowhere >* Give configuration a chance for later : start the brainstorming, define an API, make sure it works with CDI 2.0... and leave the work in the appendix so the Java EE 9 expert group can read it and decide if they should take it or not. Appendixe is just a way of saying "we've deeply thought about it, this is the way we think it should be done, now the future EG decides" > > >Antonio > > >On Mon, Sep 8, 2014 at 11:51 AM, Romain Manni-Bucau wrote: > >@Antonio: -1 for an appendix, bean validation is the example it is >>broken. Idea is awesome, everybody liked it so it was added -> great. >>Here everybody already agrees it is good so no need of "staging" phase >>IMHO. BV appendix was not the API used so it broke apps using it. SO >>using proprietary stuff is the same, it basically mean an appendix >>spec for something not under discussion (regarding its need) is IMHO >>useless. >> >> >>Romain Manni-Bucau >>Twitter: @rmannibucau >>Blog: http://rmannibucau.wordpress.com/ >>LinkedIn: http://fr.linkedin.com/in/rmannibucau >>Github: https://github.com/rmannibucau >> >> >> >>2014-09-08 10:29 GMT+02:00 Werner Keil : >>> Hi, >>> >>> If it's not really usable as API or annotation I don't see much value in >>> adding some "how to" or intent for the future into the Spec Document. >>> >>> If it was to become a part of CDI 2, there's nothing against optionality >>> like MEEP 8 or JSR 363 already practice on the SE/EE side either. >>> >>> Agorava/DeltaSpike demonstrate how true modularity work, similar to the JSRs >>> mentioned above, where you have multiple module JARs/bundles instead of a >>> big monolithic one. Some JSRs like Batch also declared separate "annotation" >>> modules, so that's what CDI 2 should also do if it was a feature Inside of >>> it. >>> Calling some features optional if they're not used by every implementation >>> allows them to chose. That was also the main value of keeping @Inject a >>> separate "module" under CDI. It was never included into a JDK but used >>> independently. >>> >>> The core of a Config module would ideally work in SE, but CDI 2 already >>> declared an aim to have some modules work under SE. >>> >>> Werner >>> >>> Am 08.09.2014 09:47 schrieb "Antonio Goncalves" >>> : >>> >>>> Hi all, >>>> >>>> I really have some concerns about adding configuration into CDI but I can >>>> see benefits too. And what about adding it... and not adding it at the same >>>> time ? In Bean Validation 1.0, the Expert Group decided not to include >>>> method-level validation in the spec (it was included in 1.1). But what they >>>> did is to add it as a proposal in the Appendix. >>>> >>>> If we feel some configuration should get in, why not have a proposal in >>>> the Appendix of CDI 2.0 ? It could then be implemented by Weld (and >>>> OpenWebBeans if they feel like it). And then, if it's successful and things >>>> get easier, get its own JSR for Java EE 9. >>>> >>>> WDYT ? >>>> >>>> Antonio >>>> >>>> On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau >>>> wrote: >>>>> >>>>> Hmm >>>>> >>>>> I see config jsr as a jse spec which would allow EE injections in config >>>>> components in EE containers (exactly like jbatch). >>>>> >>>>> This way it can be used without any container or with any container >>>>> easily. Only limit will be to not do something cdi/known containers will not >>>>> support I think. >>>>> >>>>> Not sure EE side is needed today, a lot can already be done without it >>>>> and it can be enhanced later adding some integration words. >>>>> >>>>> Le 8 sept. 2014 00:01, "Anatole Tresch" a ?crit : >>>>> >>>>>> Hi Romain >>>>>> >>>>>> just a few remarks inline... >>>>>> >>>>>> Summarizing >>>>>> 1) injection of values, reinjection, feedback on config changes can all >>>>>> be done with already existing features (producers, extensions). >>>>>> 2) configuring/bootstrapping CDI itself, e.g. configuration, is targeted >>>>>> with CDI 2.0 (see spec failing) >>>>>> >>>>>> So basically we could try to look if there is enough interest to >>>>>> standardize configuration in a more general way. For deployment aspects we >>>>>> need an EE JSR, for the rest, another SE standard may be an option as >>>>>> well... tbd... >>>>>> >>>>>> -Anatole >>>>>> >>>>>> >>>>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : >>>>>>> >>>>>>> well sorry to pop in so late but here are my 2cts >>>>>> >>>>>> easy ;) >>>>>> >>>>>>> >>>>>>> Config JSR is more about environment config IMHO and putting it in CDI >>>>>>> doesn't make sense since more or more spec works without any other >>>>>>> spec - CDI in our case. >>>>>> >>>>>> CDI even with some config mechanism added would still work "standalone". >>>>>> >>>>>> >>>>>>> >>>>>>> This mean CDI can't be the place but should >>>>>>> just be the bridge for config JSR. >>>>>> >>>>>> As I suggested as well. >>>>>> >>>>>> >>>>>>> >>>>>>> Plus CDI config will surely highly >>>>>>> be an application config first (beans.xml should be the place then) >>>>>> >>>>>> Yes, app config, but beware people of writing config into beans.xml. >>>>>> That is definitively in most cases not what you want. CDI should not define, >>>>>> where and how config is located and formatted. CDI should provide a SPI, >>>>>> where config providers can publish the configured values, so it can be >>>>>> injected wherever needed. E.g. some kind of producer, that can provide >>>>>> multiple objects to be injected and can benefit from some kind of callback >>>>>> mechanism would be sufficient... >>>>>> >>>>>>> >>>>>>> then environment config can be done at EE level (saying it has to >>>>>>> support placeholders or any pre deployment processing). >>>>>> >>>>>> Config is much more complex. There is no clear border what is >>>>>> environment config or environment dependent and what not. This depends on >>>>>> what kind of application you have deployed. As an example the email address, >>>>>> where you send error messages, can be different depenending on the >>>>>> stage/environment, but this is not EE related config entry. Also what an >>>>>> environment is, is not a thing that you can define completely. So I agree >>>>>> not to add this complexities to CDI, I would hide them between some kind of >>>>>> "config provider", as mentioned above. CDI does not need to know if the >>>>>> config provided is environment dependent or not, its just what is visible at >>>>>> a current runtime state... >>>>>> >>>>>>> >>>>>>> If you put something like ProjectStage in CDI it is great but then you >>>>>>> have it in JSF, CDI and finally surely all specs...same as >>>>>>> converters... >>>>>> >>>>>> That was originally the idea, when doing a EE config JSR, but without >>>>>> such standard. I agree, CDI is not the place to define them. >>>>>> >>>>>> >>>>>>> >>>>>>> Config should really be split in: >>>>>>> 1) spec dependent config -> spec.xml >>>>>>> 2) *common* config (a bit like javax.annotation) for environment and >>>>>>> external configuration -> Config JSR >>>>>> >>>>>> Not 100% sure, if a get the point here... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : >>>>>>> >>>>>>> well sorry to pop in so late but here are my 2cts >>>>>>> >> >>>>>>> Config JSR is more about environment config IMHO and putting it in CDI >>>>>>> doesn't make sense since more or more spec works without any other >>>>>>> spec - CDI in our case. This mean CDI can't be the place but should >>>>>>> just be the bridge for config JSR. Plus CDI config will surely highly >>>>>>> be an application config first (beans.xml should be the place then) >>>>>>> then environment config can be done at EE level (saying it has to >>>>>>> support placeholders or any pre deployment processing). >>>>>>> >>>>>>> If you put something like ProjectStage in CDI it is great but then you >>>>>>> have it in JSF, CDI and finally surely all specs...same as >>>>>>> converters... >>>>>>> >>>>>>> Config should really be split in: >>>>>>> 1) spec dependent config -> spec.xml >>>>>>> 2) *common* config (a bit like javax.annotation) for environment and >>>>>>> external configuration -> Config JSR >>>>>>> >>>>>>> wdyt? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> Twitter: @rmannibucau >>>>>>> Blog: http://rmannibucau.wordpress.com/ >>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>>>> Github: https://github.com/rmannibucau >>>>>>> >>>>>>> >>>>>>> 2014-09-07 23:39 GMT+02:00 Werner Keil : >>>>>>> > Sounds like an argument for a CDI module rather than a separate JSR >>>>>>> > then?;-) >>>>>>> > >>>>>>> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch >>>>>>> > wrote: >>>>>>> >> >>>>>>> >> I would not worry about CDI regarding licensing. Just the sentence >>>>>>> >> was >>>>>>> >> that Oracle does not want to have more ALv2 in addition to what is >>>>>>> >> already >>>>>>> >> there. So as long as we do things within CDI, no worries, I think. >>>>>>> >> For new >>>>>>> >> EE JSRs nevertheless this is a BIG issue and should be clarified by >>>>>>> >> the EC! >>>>>>> >> >>>>>>> >> >>>>>>> >> 2014-09-07 21:44 GMT+02:00 Werner Keil : >>>>>>> >>> >>>>>>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under >>>>>>> >>> ALv2 >>>>>>> >>> as a dual-license, this was discussed by EC Members but both JCP EC >>>>>>> >>> and >>>>>>> >>> Oracle Legal/PMO seems fine with it, and CDI is already an >>>>>>> >>> essential >>>>>>> >>> building block to Java EE 6/7, hence used with Glassfish, too. I >>>>>>> >>> wasn't >>>>>>> >>> involved in these discussions, but given CDI is especially liberal >>>>>>> >>> and fully >>>>>>> >>> accepted by JCP formalities and license policies, I don't really >>>>>>> >>> see what >>>>>>> >>> the problem wss for Anatole's JSR attempt (though I know, both >>>>>>> >>> Oracle and >>>>>>> >>> other EC Members/companies don't always prefer this kind of >>>>>>> >>> licensing...;-) >>>>>>> >>> >>>>>>> >>> Werner >>>>>>> >>> >>>>>>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament >>>>>>> >>> >>>>>>> >>> wrote: >>>>>>> >>>> >>>>>>> >>>> Ok, this mail has me more concerned than anything. Can you >>>>>>> >>>> clarify this >>>>>>> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. >>>>>>> >>>> >>>>>>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch >>>>>>> >>>> >>>>>>> >>>> wrote: >>>>>>> >>>>> >>>>>>> >>>>> Hi All >>>>>>> >>>>> >>>>>>> >>>>> unfortunately things seem quite complicated: >>>>>>> >>>>> >>>>>>> >>>>> first of all, similarities with Deltaspike are basically not >>>>>>> >>>>> accidental. The concepts we developed in Credit Suisse are very >>>>>>> >>>>> similar to >>>>>>> >>>>> Deltaspike, though Deltaspike was not yet born at that time. >>>>>>> >>>>> Fortunately we >>>>>>> >>>>> ended up with a similar kind of solution. >>>>>>> >>>>> filtering still can be done. My idea is to define some kind of >>>>>>> >>>>> "configuration provider", which then is dynamically asked for >>>>>>> >>>>> configuration. >>>>>>> >>>>> How the provider is internally organized, is completely >>>>>>> >>>>> transparent to CDI. >>>>>>> >>>>> This enables to have multi-layered, complex config solutions work >>>>>>> >>>>> the same >>>>>>> >>>>> (from a view point of CDI) like simple programmatic test >>>>>>> >>>>> configurations >>>>>>> >>>>> during unit tests. The config provider still can support >>>>>>> >>>>> filtering and >>>>>>> >>>>> dynamic resolution as commonly used in configuration systems. >>>>>>> >>>>> Similarly the >>>>>>> >>>>> format is basically also not fixed. Of course, would a reference >>>>>>> >>>>> implementation provide a set of functionalities, but I would >>>>>>> >>>>> definitively >>>>>>> >>>>> not define the exact configuration mechanism as part of the CDI >>>>>>> >>>>> (or even a >>>>>>> >>>>> EE config JSR). Another reason, beside complexity and time, is >>>>>>> >>>>> the fact that >>>>>>> >>>>> different companies handle, store and manage configuration >>>>>>> >>>>> differently, so a >>>>>>> >>>>> mechanism must be flexible enough to accommodate these, without >>>>>>> >>>>> adoption >>>>>>> >>>>> rate will be low. Furthermore this flexibility also keeps doors >>>>>>> >>>>> open for use >>>>>>> >>>>> cases we do not know yet. >>>>>>> >>>>> Also we have to separate some basically two types of >>>>>>> >>>>> configuration >>>>>>> >>>>> aspects: >>>>>>> >>>>> >>>>>>> >>>>> application config basically is injected into deployed >>>>>>> >>>>> components, but >>>>>>> >>>>> basically only can affect deployment to the extend it can be >>>>>>> >>>>> managed and >>>>>>> >>>>> injected by CDI. The basic architecture and design, how >>>>>>> >>>>> application servers >>>>>>> >>>>> to load and deploy are basically not affected. This type of >>>>>>> >>>>> configuration >>>>>>> >>>>> (mechanism) I see also as a possible addition to CDI, if we >>>>>>> >>>>> really fail to >>>>>>> >>>>> do something in another JSR. With CDI going for a more modular >>>>>>> >>>>> design, even >>>>>>> >>>>> basic configuration of CDI can be possible, given we have some >>>>>>> >>>>> kind of API, >>>>>>> >>>>> we can access during CDI initialization. >>>>>>> >>>>> On the other side deployment configuration affects directly how >>>>>>> >>>>> the >>>>>>> >>>>> application server deploys the application. Configuration here >>>>>>> >>>>> would allow >>>>>>> >>>>> to define datasources, EJBs, transactional aspects, security, >>>>>>> >>>>> persistence, >>>>>>> >>>>> war and ear configurations etc. Basically everything you do as of >>>>>>> >>>>> today with >>>>>>> >>>>> some kind of XML file, or annotation. Hereby enabling more >>>>>>> >>>>> flexibility into >>>>>>> >>>>> the existing descriptors is relatively easy, but as mentioned by >>>>>>> >>>>> Mark, >>>>>>> >>>>> constraint. Adding more flexibility raises other subtle problems. >>>>>>> >>>>> Imagine a >>>>>>> >>>>> application module, e.g. a war, that defines everything it >>>>>>> >>>>> requires. There >>>>>>> >>>>> is no need to configure anything more on server side (with spring >>>>>>> >>>>> you can do >>>>>>> >>>>> this, with Java EE unfortunately not). But this has a severe >>>>>>> >>>>> consequence, it >>>>>>> >>>>> would make the application really portable in the sense, that it >>>>>>> >>>>> can be >>>>>>> >>>>> moved between different app servers (vendors) without any change >>>>>>> >>>>> (ideally). >>>>>>> >>>>> As a result commercial profits of some vendor companies may be >>>>>>> >>>>> affected. I >>>>>>> >>>>> think this is actually one of the key points, why things are >>>>>>> >>>>> getting so >>>>>>> >>>>> complicated in that area. >>>>>>> >>>>> >>>>>>> >>>>> Legal aspects also were discussed. One of them is a possible >>>>>>> >>>>> legal >>>>>>> >>>>> clash of ALv2 with GPL. This is the case already within >>>>>>> >>>>> Glassfish, but one >>>>>>> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal >>>>>>> >>>>> department. At >>>>>>> >>>>> the end we decided to use a BSD model. Even dual licensing >>>>>>> >>>>> BSD/ALv2 could >>>>>>> >>>>> theoretically be an option. If you would choose ALv2, Oracle will >>>>>>> >>>>> not >>>>>>> >>>>> include your RI into Glassfish, which is the RI for the EE >>>>>>> >>>>> Umbrella JSR, >>>>>>> >>>>> meaning your JSR will not be included into EE8. So what should we >>>>>>> >>>>> do? I >>>>>>> >>>>> don't have a good answer... >>>>>>> >>>>> >>>>>>> >>>>> So, I like to discuss configuration aspects here. Nevertheless if >>>>>>> >>>>> we >>>>>>> >>>>> decide to add config aspects, be aware that we might only >>>>>>> >>>>> (mainly) support >>>>>>> >>>>> application config, since everything else directly would impact >>>>>>> >>>>> other JSRs. >>>>>>> >>>>> And that is obviously quite similar to what Apache Deltaspike is >>>>>>> >>>>> all about >>>>>>> >>>>> ;-) >>>>>>> >>>>> >>>>>>> >>>>> Cheers, >>>>>>> >>>>> Anatole >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : >>>>>>> >>>>>> >>>>>>> >>>>>> Yes, the config group also was (obviously) looking at >>>>>>> >>>>>> DeltaSpikes >>>>>>> >>>>>> config mechanism as well. >>>>>>> >>>>>> There were others who wanted to go more into the 'filtering' >>>>>>> >>>>>> approach >>>>>>> >>>>>> as done on WebLogic servers (though not sure who else does that >>>>>>> >>>>>> as well). >>>>>>> >>>>>> You know, having all the XML configs like WEB-INF/web.xml >>>>>>> >>>>>> containing >>>>>>> >>>>>> placeholders and the real values only get placed in there at >>>>>>> >>>>>> deployment >>>>>>> >>>>>> time. I personally find this approach a bit limited from a >>>>>>> >>>>>> technical >>>>>>> >>>>>> perspective and it already didn't work out for me when using >>>>>>> >>>>>> WebLogic (what >>>>>>> >>>>>> about changing a configured value after the deployment was done? >>>>>>> >>>>>> What about >>>>>>> >>>>>> security? Having passwords in web.xml, unit testing, ...). >>>>>>> >>>>>> There are of course also other approaches which all might have >>>>>>> >>>>>> strong >>>>>>> >>>>>> sides and would have needed to get discussed. >>>>>>> >>>>>> >>>>>>> >>>>>> But utterly the problem seems to have been legal reasons. We >>>>>>> >>>>>> even >>>>>>> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF >>>>>>> >>>>>> project with >>>>>>> >>>>>> substantial support and participation from the JBoss, DeltaSpike >>>>>>> >>>>>> and TomEE >>>>>>> >>>>>> communities. >>>>>>> >>>>>> >>>>>>> >>>>>> Anyway, the time will come when we will resurrect this effort. >>>>>>> >>>>>> >>>>>>> >>>>>> LieGrue, >>>>>>> >>>>>> strub >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil >>>>>>> >>>>>> wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Yep, it contains a simple but extendable notion of ProjectStage, >>>>>>> >>>>>> too;-) >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament >>>>>>> >>>>>> >>>>>>> >>>>>> wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> Anatole, >>>>>>> >>>>>> >>>>>>> >>>>>> I'm wondering if some of your configuration description falls >>>>>>> >>>>>> under >>>>>>> >>>>>> what was put together in DeltaSpike? >>>>>>> >>>>>> >>>>>>> >>>>>> http://deltaspike.apache.org/configuration.html >>>>>>> >>>>>> >>>>>>> >>>>>> John >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch >>>>>>> >>>>>> >>>>>>> >>>>>> wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> Staging is not a question of xml or not xml (the "format" of >>>>>>> >>>>>> config). >>>>>>> >>>>>> You can do staged config also using xml, or based on a database >>>>>>> >>>>>> or json >>>>>>> >>>>>> config service. Staging as well as, more generally speaking, >>>>>>> >>>>>> environment >>>>>>> >>>>>> dependent config is more like to select/filter the right config >>>>>>> >>>>>> that targets >>>>>>> >>>>>> the current (runtime) environment. This might include stages, >>>>>>> >>>>>> but also many >>>>>>> >>>>>> other aspects are feasible and common (server, tier, ear, war, >>>>>>> >>>>>> tenant ...). >>>>>>> >>>>>> Since these aspects are per se very complex, it might be >>>>>>> >>>>>> advisable to leave >>>>>>> >>>>>> them out of any spec (even a dedicated config JSR would probably >>>>>>> >>>>>> not be >>>>>>> >>>>>> capable of covering these within the relatively short EE >>>>>>> >>>>>> timeframe)... >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil : >>>>>>> >>>>>> >>>>>>> >>>>>> Jens/all, >>>>>>> >>>>>> >>>>>>> >>>>>> A sort of "staging" already was possible using CDI earlier, see >>>>>>> >>>>>> examples like this: >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >>>>>>> >>>>>> >>>>>>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond the >>>>>>> >>>>>> primitive, hard-coded JSF enum. >>>>>>> >>>>>> >>>>>>> >>>>>> If that works without XML, while still allowing flexible >>>>>>> >>>>>> configuration >>>>>>> >>>>>> for different stages or to add and "inject" additional stages >>>>>>> >>>>>> maybe even on >>>>>>> >>>>>> a tenant basis (for Cloud scenarios) I could see something like >>>>>>> >>>>>> that work >>>>>>> >>>>>> without XML. In the Multiconf project we managed to code >>>>>>> >>>>>> everything in >>>>>>> >>>>>> Python, and similar to Puppet or Chef you can configure and >>>>>>> >>>>>> deploy multiple >>>>>>> >>>>>> environments with it, Java EE, Spring or Play! several of them >>>>>>> >>>>>> are >>>>>>> >>>>>> configured this way and it requires no XML (where the container >>>>>>> >>>>>> needs such >>>>>>> >>>>>> files, the framework generates them;-) >>>>>>> >>>>>> >>>>>>> >>>>>> Werner >>>>>>> >>>>>> >>>>>>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, >>>>>>> >>>>>> >>>>>>> >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole >>>>>>> >>>>>> Tresch) >>>>>>> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >>>>>>> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>>>>>> >>>>>> (Anatole Tresch (JIRA)) >>>>>>> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) >>>>>>> >>>>>> >>>>>>> >>>>>> ------------------------------ >>>>>>> >>>>>> >>>>>>> >>>>>> Message: 4 >>>>>>> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >>>>>>> >>>>>> From: Jens Schumann >>>>>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... >>>>>>> >>>>>> To: Anatole Tresch , Antonio Goncalves >>>>>>> >>>>>> >>>>>>> >>>>>> Cc: cdi-dev >>>>>>> >>>>>> Message-ID: >>>>>>> >>>>>> Content-Type: text/plain; charset="windows-1252" >>>>>>> >>>>>> >>>>>>> >>>>>> I can confirm that this approach works very well. We are using a >>>>>>> >>>>>> similar approach a couple of years now, and I love the >>>>>>> >>>>>> simplicity that comes >>>>>>> >>>>>> with portable extensions and @Producer methods. See our public >>>>>>> >>>>>> version here >>>>>>> >>>>>> [1] (works since early CDI 1.0 days) . >>>>>>> >>>>>> >>>>>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier >>>>>>> >>>>>> @Property. >>>>>>> >>>>>> We support default values and type conversation for primitives >>>>>>> >>>>>> and >>>>>>> >>>>>> everything that has a string based constructor. The property >>>>>>> >>>>>> source can be >>>>>>> >>>>>> anything, from property files (default) to databases or xml >>>>>>> >>>>>> files. For >>>>>>> >>>>>> examples see tests here [2]. >>>>>>> >>>>>> >>>>>>> >>>>>> Nevertheless I am not sure if this should be part of an future >>>>>>> >>>>>> CDI >>>>>>> >>>>>> spec. My concerns include the bloat argument, of course. But the >>>>>>> >>>>>> main reason >>>>>>> >>>>>> relates to the fact that we have almost everything in the >>>>>>> >>>>>> current CDI spec >>>>>>> >>>>>> already. >>>>>>> >>>>>> >>>>>>> >>>>>> Right now I am quite happy with an custom portable extension >>>>>>> >>>>>> that does >>>>>>> >>>>>> everything for me. At the time we implemented the extension we >>>>>>> >>>>>> realised that >>>>>>> >>>>>> the "hard part" was writing an extension that links a qualified >>>>>>> >>>>>> "optional >>>>>>> >>>>>> injection point" with an @Producer method while supporting code >>>>>>> >>>>>> based >>>>>>> >>>>>> default values. Luckily I had Arne in my team who did that >>>>>>> >>>>>> within a few >>>>>>> >>>>>> minutes. >>>>>>> >>>>>> >>>>>>> >>>>>> Because of this experience I would propose that we simplify >>>>>>> >>>>>> extension >>>>>>> >>>>>> development such that "optional injection points" may be linked >>>>>>> >>>>>> to @Produces >>>>>>> >>>>>> values easily. Additionally we have to solve a few more >>>>>>> >>>>>> integration issues >>>>>>> >>>>>> (e.g. read-only DB access should be available during CDI >>>>>>> >>>>>> startup). >>>>>>> >>>>>> Everything else should be provided by portable extensions (e.g. >>>>>>> >>>>>> via >>>>>>> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. >>>>>>> >>>>>> >>>>>>> >>>>>> Jens >>>>>>> >>>>>> [1] >>>>>>> >>>>>> >>>>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >>>>>>> >>>>>> [2] >>>>>>> >>>>>> >>>>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >>>>>>> >>>>>> >>>>>>> >>>>>> Von: Anatole Tresch >>>>>>> >>>>>> > >>>>>>> >>>>>> Datum: Friday 5 September 2014 21:22 >>>>>>> >>>>>> An: Antonio Goncalves >>>>>>> >>>>>> >>>>>>> >>>>>> > >>>>>>> >>>>>> Cc: CDI-Dev >>>>>>> >>>>>> > >>>>>>> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... >>>>>>> >>>>>> >>>>>>> >>>>>> Hi all, >>>>>>> >>>>>> >>>>>>> >>>>>> I would not like to add an XML "bloated" mechanism as part of >>>>>>> >>>>>> CDI 2.0. >>>>>>> >>>>>> Spontaneously I would propose a more CDI like things like: >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> * Adding a @Configured annotation (basically a qualifier). >>>>>>> >>>>>> This >>>>>>> >>>>>> can be in addition to @Inject and would allow to inject >>>>>>> >>>>>> "configured" values. >>>>>>> >>>>>> * Since configuration can change we may think of a (CDI) >>>>>>> >>>>>> event/reinject mechanism based on config changes. By default, >>>>>>> >>>>>> this is >>>>>>> >>>>>> switched off and we can discuss how it would be activated, e.g. >>>>>>> >>>>>> by an >>>>>>> >>>>>> additional flag settable with the @Configured annotation, or an >>>>>>> >>>>>> additional >>>>>>> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon >>>>>>> >>>>>> framework), or both. >>>>>>> >>>>>> * Hereby configured values theoretically behave similar as >>>>>>> >>>>>> all >>>>>>> >>>>>> other injection points. They also can be qualified (the aspect >>>>>>> >>>>>> of scopes, I >>>>>>> >>>>>> did not yet have time to think about). The only difference is, >>>>>>> >>>>>> that they are >>>>>>> >>>>>> satisified using the configuration "system". >>>>>>> >>>>>> * The configuration "source" itself could in the extreme >>>>>>> >>>>>> simplest >>>>>>> >>>>>> way be a Provider>. The CDI spec should not >>>>>>> >>>>>> care about >>>>>>> >>>>>> how this map is provided (XML, DB, overrides, etc). This still >>>>>>> >>>>>> can be >>>>>>> >>>>>> standardized later. As long as the ConfigurationSource SPI is >>>>>>> >>>>>> defined, >>>>>>> >>>>>> companies still can hook in the logic and level of configuration >>>>>>> >>>>>> abstraction >>>>>>> >>>>>> they need. >>>>>>> >>>>>> * Of course, since not only Strings can be injected, we need >>>>>>> >>>>>> some >>>>>>> >>>>>> conversion or adapter logic as basically outlined in my blog. >>>>>>> >>>>>> Also here we >>>>>>> >>>>>> can add a simple SPI and let the details to the RI. >>>>>>> >>>>>> >>>>>>> >>>>>> Summarizing a >>>>>>> >>>>>> >>>>>>> >>>>>> * @Configured annotation >>>>>>> >>>>>> * some kind of change event >>>>>>> >>>>>> * a ConfigurationSource extends Provider> >>>>>>> >>>>>> * a conversion mechanism from String to T. >>>>>>> >>>>>> >>>>>>> >>>>>> we get a full fledged configuration mechanism that leverages >>>>>>> >>>>>> CDI. >>>>>>> >>>>>> >>>>>>> >>>>>> That would be my idea basically. WDYT? I will try to work that >>>>>>> >>>>>> out in >>>>>>> >>>>>> more details. Basically it should be implementable even with the >>>>>>> >>>>>> CDI >>>>>>> >>>>>> mechanism already in place with CDI 1.1. >>>>>>> >>>>>> >>>>>>> >>>>>> Best, >>>>>>> >>>>>> Anatole >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >>>>>>> >>>>>> >>>>>>> >>>>>> >: >>>>>>> >>>>>> One wise man* once said "EJB was a hype specification, we added >>>>>>> >>>>>> too >>>>>>> >>>>>> many things to it, it became bloated. The next hype >>>>>>> >>>>>> specifications are >>>>>>> >>>>>> JAX-RS and CDI, careful with them" >>>>>>> >>>>>> >>>>>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup >>>>>>> >>>>>> being >>>>>>> >>>>>> bloated. >>>>>>> >>>>>> >>>>>>> >>>>>> Antonio >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> *David Blevin >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand >>>>>>> >>>>>> > >>>>>>> >>>>>> wrote: >>>>>>> >>>>>> Hi all, >>>>>>> >>>>>> >>>>>>> >>>>>> You may have followed the rise and fall of the Java Config JSR >>>>>>> >>>>>> >>>>>>> >>>>>> (http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html). >>>>>>> >>>>>> Anatole in CC was leading this initiative and I proposed him to >>>>>>> >>>>>> join >>>>>>> >>>>>> us and explore if some part of his late-JSR could be done in >>>>>>> >>>>>> CDI. >>>>>>> >>>>>> >>>>>>> >>>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 >>>>>>> >>>>>> or >>>>>>> >>>>>> related solution. If we achieve to have a majority of specs to >>>>>>> >>>>>> integrate >>>>>>> >>>>>> with CDI, our configuration solution would therefore become a >>>>>>> >>>>>> configuration >>>>>>> >>>>>> system for all spec based on CDI 2.0. >>>>>>> >>>>>> >>>>>>> >>>>>> 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. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> -- >>>>>>> >>>>>> Antonio Goncalves >>>>>>> >>>>>> Software architect, Java Champion and Pluralsight author >>>>>>> >>>>>> >>>>>>> >>>>>> Web site | >>>>>>> >>>>>> Twitter | >>>>>>> >>>>>> LinkedIn | >>>>>>> >>>>>> >>>>>>> >>>>>> Pluralsight >>>>>>> >>>>>> | Paris JUG | Devoxx >>>>>>> >>>>>> France >>>>>>> >>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>>> >>>>>> 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. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> -- >>>>>>> >>>>>> Anatole Tresch >>>>>>> >>>>>> Java Lead Engineer, JSR Spec Lead >>>>>>> >>>>>> Gl?rnischweg 10 >>>>>>> >>>>>> CH - 8620 Wetzikon >>>>>>> >>>>>> >>>>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>>>>>> >>>>>> Twitter: @atsticks >>>>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>>>>> >>>>>> Google: atsticks >>>>>>> >>>>>> Mobile +41-76 344 62 79 >>>>>>> >>>>>> -------------- next part -------------- >>>>>>> >>>>>> An HTML attachment was scrubbed... >>>>>>> >>>>>> URL: >>>>>>> >>>>>> >>>>>>> >>>>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >>>>>>> >>>>>> *************************************** >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>>> >>>>>> 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. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> -- >>>>>>> >>>>>> Anatole Tresch >>>>>>> >>>>>> Java Lead Engineer, JSR Spec Lead >>>>>>> >>>>>> Gl?rnischweg 10 >>>>>>> >>>>>> CH - 8620 Wetzikon >>>>>>> >>>>>> >>>>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>>>>>> >>>>>> Twitter: @atsticks >>>>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>>>>> >>>>>> Google: atsticks >>>>>>> >>>>>> Mobile +41-76 344 62 79 >>>>>>> >>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>>> >>>>>> 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. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>>> >>>>>> 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. >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> -- >>>>>>> >>>>> Anatole Tresch >>>>>>> >>>>> Java Lead Engineer, JSR Spec Lead >>>>>>> >>>>> Gl?rnischweg 10 >>>>>>> >>>>> CH - 8620 Wetzikon >>>>>>> >>>>> >>>>>>> >>>>> Switzerland, Europe Zurich, GMT+1 >>>>>>> >>>>> Twitter: @atsticks >>>>>>> >>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>>>>> >>>>> Google: atsticks >>>>>>> >>>>> Mobile +41-76 344 62 79 >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> -- >>>>>>> >> Anatole Tresch >>>>>>> >> Java Lead Engineer, JSR Spec Lead >>>>>>> >> Gl?rnischweg 10 >>>>>>> >> CH - 8620 Wetzikon >>>>>>> >> >>>>>>> >> Switzerland, Europe Zurich, GMT+1 >>>>>>> >> Twitter: @atsticks >>>>>>> >> Blogs: http://javaremarkables.blogspot.ch/ >>>>>>> >> Google: atsticks >>>>>>> >> Mobile +41-76 344 62 79 >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > 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. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Anatole Tresch >>>>>> Java Lead Engineer, JSR Spec Lead >>>>>> Gl?rnischweg 10 >>>>>> CH - 8620 Wetzikon >>>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>>>>> Twitter: @atsticks >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>>>> Google: atsticks >>>>>> Mobile +41-76 344 62 79 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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. >>>> >>>> >>>> >>>> >>>> -- >>>> Antonio Goncalves >>>> Software architect, Java Champion and Pluralsight author >>>> >>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >> > > > >-- > >Antonio Goncalves >Software architect, Java Champion and Pluralsight author > >Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >_______________________________________________ >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/20140908/e2334450/attachment-0001.html From antoine at sabot-durand.net Mon Sep 8 11:25:29 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 8 Sep 2014 17:25:29 +0200 Subject: [cdi-dev] With the end of Java Config... In-Reply-To: References: <1410094004.18964.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Well said. Now, to take another point of view, there are framework out there which need "out of code" configuration. The first to come to my mind is Camel which use an XML file to configure routes. I?m sure we can find the same use case in BPM or engine rule side. I?m not a big fan of XML / JSon or whatever config file, but sometimes changing the code to configure a behaviour is not acceptable (and not very Devops friendly). Do we really want CDI to be excluded from these use cases (Camel continues to favorite Spring or Blueprint because of this)? We have 3 ways to answer to this expectation IMO : 1) It?s not our problem : developing a mechanism to read config in DB or file is possible thru extension so don?t bother us with adding config to the spec. 2) It?s not our problem but... we understand this need and will work to add to the spec new APIs to ease the development of a config reader (for example by standardising Deltaspike AnnotatedTypeBuilder) 3) We agree that its a real feature lacking to CDI. And we understand that without a standard, frameworks needing config files will continue to avoid CDI or will use specific file format creating proprietary format. I?m not saying we should go for 3) (but I like Antonio?s annexe idea) I?m saying we should take an explicit statement about that because today in the spec we have that : http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#alternative_metadata_sources which reads (for me) ?we could have done it but in the end we didn?t?. Not very end user friendly. Antoine > Le 8 sept. 2014 ? 15:31, Antonio Goncalves a ?crit : > > It's just a matter of knowing what we want to do : > > * Add configuration into CDI 2.0 : it goes into the spec > * Forget about configuration : it goes nowhere > * Give configuration a chance for later : start the brainstorming, define an API, make sure it works with CDI 2.0... and leave the work in the appendix so the Java EE 9 expert group can read it and decide if they should take it or not. Appendixe is just a way of saying "we've deeply thought about it, this is the way we think it should be done, now the future EG decides" > > Antonio > > On Mon, Sep 8, 2014 at 11:51 AM, Romain Manni-Bucau > wrote: > @Antonio: -1 for an appendix, bean validation is the example it is > broken. Idea is awesome, everybody liked it so it was added -> great. > Here everybody already agrees it is good so no need of "staging" phase > IMHO. BV appendix was not the API used so it broke apps using it. SO > using proprietary stuff is the same, it basically mean an appendix > spec for something not under discussion (regarding its need) is IMHO > useless. > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > 2014-09-08 10:29 GMT+02:00 Werner Keil >: > > Hi, > > > > If it's not really usable as API or annotation I don't see much value in > > adding some "how to" or intent for the future into the Spec Document. > > > > If it was to become a part of CDI 2, there's nothing against optionality > > like MEEP 8 or JSR 363 already practice on the SE/EE side either. > > > > Agorava/DeltaSpike demonstrate how true modularity work, similar to the JSRs > > mentioned above, where you have multiple module JARs/bundles instead of a > > big monolithic one. Some JSRs like Batch also declared separate "annotation" > > modules, so that's what CDI 2 should also do if it was a feature Inside of > > it. > > Calling some features optional if they're not used by every implementation > > allows them to chose. That was also the main value of keeping @Inject a > > separate "module" under CDI. It was never included into a JDK but used > > independently. > > > > The core of a Config module would ideally work in SE, but CDI 2 already > > declared an aim to have some modules work under SE. > > > > Werner > > > > Am 08.09.2014 09:47 schrieb "Antonio Goncalves" > > >: > > > >> Hi all, > >> > >> I really have some concerns about adding configuration into CDI but I can > >> see benefits too. And what about adding it... and not adding it at the same > >> time ? In Bean Validation 1.0, the Expert Group decided not to include > >> method-level validation in the spec (it was included in 1.1). But what they > >> did is to add it as a proposal in the Appendix. > >> > >> If we feel some configuration should get in, why not have a proposal in > >> the Appendix of CDI 2.0 ? It could then be implemented by Weld (and > >> OpenWebBeans if they feel like it). And then, if it's successful and things > >> get easier, get its own JSR for Java EE 9. > >> > >> WDYT ? > >> > >> Antonio > >> > >> On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau > > >> wrote: > >>> > >>> Hmm > >>> > >>> I see config jsr as a jse spec which would allow EE injections in config > >>> components in EE containers (exactly like jbatch). > >>> > >>> This way it can be used without any container or with any container > >>> easily. Only limit will be to not do something cdi/known containers will not > >>> support I think. > >>> > >>> Not sure EE side is needed today, a lot can already be done without it > >>> and it can be enhanced later adding some integration words. > >>> > >>> Le 8 sept. 2014 00:01, "Anatole Tresch" > a ?crit : > >>> > >>>> Hi Romain > >>>> > >>>> just a few remarks inline... > >>>> > >>>> Summarizing > >>>> 1) injection of values, reinjection, feedback on config changes can all > >>>> be done with already existing features (producers, extensions). > >>>> 2) configuring/bootstrapping CDI itself, e.g. configuration, is targeted > >>>> with CDI 2.0 (see spec failing) > >>>> > >>>> So basically we could try to look if there is enough interest to > >>>> standardize configuration in a more general way. For deployment aspects we > >>>> need an EE JSR, for the rest, another SE standard may be an option as > >>>> well... tbd... > >>>> > >>>> -Anatole > >>>> > >>>> > >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau >: > >>>>> > >>>>> well sorry to pop in so late but here are my 2cts > >>>> > >>>> easy ;) > >>>> > >>>>> > >>>>> Config JSR is more about environment config IMHO and putting it in CDI > >>>>> doesn't make sense since more or more spec works without any other > >>>>> spec - CDI in our case. > >>>> > >>>> CDI even with some config mechanism added would still work "standalone". > >>>> > >>>> > >>>>> > >>>>> This mean CDI can't be the place but should > >>>>> just be the bridge for config JSR. > >>>> > >>>> As I suggested as well. > >>>> > >>>> > >>>>> > >>>>> Plus CDI config will surely highly > >>>>> be an application config first (beans.xml should be the place then) > >>>> > >>>> Yes, app config, but beware people of writing config into beans.xml. > >>>> That is definitively in most cases not what you want. CDI should not define, > >>>> where and how config is located and formatted. CDI should provide a SPI, > >>>> where config providers can publish the configured values, so it can be > >>>> injected wherever needed. E.g. some kind of producer, that can provide > >>>> multiple objects to be injected and can benefit from some kind of callback > >>>> mechanism would be sufficient... > >>>> > >>>>> > >>>>> then environment config can be done at EE level (saying it has to > >>>>> support placeholders or any pre deployment processing). > >>>> > >>>> Config is much more complex. There is no clear border what is > >>>> environment config or environment dependent and what not. This depends on > >>>> what kind of application you have deployed. As an example the email address, > >>>> where you send error messages, can be different depenending on the > >>>> stage/environment, but this is not EE related config entry. Also what an > >>>> environment is, is not a thing that you can define completely. So I agree > >>>> not to add this complexities to CDI, I would hide them between some kind of > >>>> "config provider", as mentioned above. CDI does not need to know if the > >>>> config provided is environment dependent or not, its just what is visible at > >>>> a current runtime state... > >>>> > >>>>> > >>>>> If you put something like ProjectStage in CDI it is great but then you > >>>>> have it in JSF, CDI and finally surely all specs...same as > >>>>> converters... > >>>> > >>>> That was originally the idea, when doing a EE config JSR, but without > >>>> such standard. I agree, CDI is not the place to define them. > >>>> > >>>> > >>>>> > >>>>> Config should really be split in: > >>>>> 1) spec dependent config -> spec.xml > >>>>> 2) *common* config (a bit like javax.annotation) for environment and > >>>>> external configuration -> Config JSR > >>>> > >>>> Not 100% sure, if a get the point here... > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau >: > >>>>> > >>>>> well sorry to pop in so late but here are my 2cts > >>>>> > >>>>> Config JSR is more about environment config IMHO and putting it in CDI > >>>>> doesn't make sense since more or more spec works without any other > >>>>> spec - CDI in our case. This mean CDI can't be the place but should > >>>>> just be the bridge for config JSR. Plus CDI config will surely highly > >>>>> be an application config first (beans.xml should be the place then) > >>>>> then environment config can be done at EE level (saying it has to > >>>>> support placeholders or any pre deployment processing). > >>>>> > >>>>> If you put something like ProjectStage in CDI it is great but then you > >>>>> have it in JSF, CDI and finally surely all specs...same as > >>>>> converters... > >>>>> > >>>>> Config should really be split in: > >>>>> 1) spec dependent config -> spec.xml > >>>>> 2) *common* config (a bit like javax.annotation) for environment and > >>>>> external configuration -> Config JSR > >>>>> > >>>>> wdyt? > >>>>> > >>>>> > >>>>> > >>>>> Romain Manni-Bucau > >>>>> Twitter: @rmannibucau > >>>>> Blog: http://rmannibucau.wordpress.com/ > >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau > >>>>> Github: https://github.com/rmannibucau > >>>>> > >>>>> > >>>>> 2014-09-07 23:39 GMT+02:00 Werner Keil >: > >>>>> > Sounds like an argument for a CDI module rather than a separate JSR > >>>>> > then?;-) > >>>>> > > >>>>> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch > > >>>>> > wrote: > >>>>> >> > >>>>> >> I would not worry about CDI regarding licensing. Just the sentence > >>>>> >> was > >>>>> >> that Oracle does not want to have more ALv2 in addition to what is > >>>>> >> already > >>>>> >> there. So as long as we do things within CDI, no worries, I think. > >>>>> >> For new > >>>>> >> EE JSRs nevertheless this is a BIG issue and should be clarified by > >>>>> >> the EC! > >>>>> >> > >>>>> >> > >>>>> >> 2014-09-07 21:44 GMT+02:00 Werner Keil >: > >>>>> >>> > >>>>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under > >>>>> >>> ALv2 > >>>>> >>> as a dual-license, this was discussed by EC Members but both JCP EC > >>>>> >>> and > >>>>> >>> Oracle Legal/PMO seems fine with it, and CDI is already an > >>>>> >>> essential > >>>>> >>> building block to Java EE 6/7, hence used with Glassfish, too. I > >>>>> >>> wasn't > >>>>> >>> involved in these discussions, but given CDI is especially liberal > >>>>> >>> and fully > >>>>> >>> accepted by JCP formalities and license policies, I don't really > >>>>> >>> see what > >>>>> >>> the problem wss for Anatole's JSR attempt (though I know, both > >>>>> >>> Oracle and > >>>>> >>> other EC Members/companies don't always prefer this kind of > >>>>> >>> licensing...;-) > >>>>> >>> > >>>>> >>> Werner > >>>>> >>> > >>>>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament > >>>>> >>> > > >>>>> >>> wrote: > >>>>> >>>> > >>>>> >>>> Ok, this mail has me more concerned than anything. Can you > >>>>> >>>> clarify this > >>>>> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. > >>>>> >>>> > >>>>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch > >>>>> >>>> > > >>>>> >>>> wrote: > >>>>> >>>>> > >>>>> >>>>> Hi All > >>>>> >>>>> > >>>>> >>>>> unfortunately things seem quite complicated: > >>>>> >>>>> > >>>>> >>>>> first of all, similarities with Deltaspike are basically not > >>>>> >>>>> accidental. The concepts we developed in Credit Suisse are very > >>>>> >>>>> similar to > >>>>> >>>>> Deltaspike, though Deltaspike was not yet born at that time. > >>>>> >>>>> Fortunately we > >>>>> >>>>> ended up with a similar kind of solution. > >>>>> >>>>> filtering still can be done. My idea is to define some kind of > >>>>> >>>>> "configuration provider", which then is dynamically asked for > >>>>> >>>>> configuration. > >>>>> >>>>> How the provider is internally organized, is completely > >>>>> >>>>> transparent to CDI. > >>>>> >>>>> This enables to have multi-layered, complex config solutions work > >>>>> >>>>> the same > >>>>> >>>>> (from a view point of CDI) like simple programmatic test > >>>>> >>>>> configurations > >>>>> >>>>> during unit tests. The config provider still can support > >>>>> >>>>> filtering and > >>>>> >>>>> dynamic resolution as commonly used in configuration systems. > >>>>> >>>>> Similarly the > >>>>> >>>>> format is basically also not fixed. Of course, would a reference > >>>>> >>>>> implementation provide a set of functionalities, but I would > >>>>> >>>>> definitively > >>>>> >>>>> not define the exact configuration mechanism as part of the CDI > >>>>> >>>>> (or even a > >>>>> >>>>> EE config JSR). Another reason, beside complexity and time, is > >>>>> >>>>> the fact that > >>>>> >>>>> different companies handle, store and manage configuration > >>>>> >>>>> differently, so a > >>>>> >>>>> mechanism must be flexible enough to accommodate these, without > >>>>> >>>>> adoption > >>>>> >>>>> rate will be low. Furthermore this flexibility also keeps doors > >>>>> >>>>> open for use > >>>>> >>>>> cases we do not know yet. > >>>>> >>>>> Also we have to separate some basically two types of > >>>>> >>>>> configuration > >>>>> >>>>> aspects: > >>>>> >>>>> > >>>>> >>>>> application config basically is injected into deployed > >>>>> >>>>> components, but > >>>>> >>>>> basically only can affect deployment to the extend it can be > >>>>> >>>>> managed and > >>>>> >>>>> injected by CDI. The basic architecture and design, how > >>>>> >>>>> application servers > >>>>> >>>>> to load and deploy are basically not affected. This type of > >>>>> >>>>> configuration > >>>>> >>>>> (mechanism) I see also as a possible addition to CDI, if we > >>>>> >>>>> really fail to > >>>>> >>>>> do something in another JSR. With CDI going for a more modular > >>>>> >>>>> design, even > >>>>> >>>>> basic configuration of CDI can be possible, given we have some > >>>>> >>>>> kind of API, > >>>>> >>>>> we can access during CDI initialization. > >>>>> >>>>> On the other side deployment configuration affects directly how > >>>>> >>>>> the > >>>>> >>>>> application server deploys the application. Configuration here > >>>>> >>>>> would allow > >>>>> >>>>> to define datasources, EJBs, transactional aspects, security, > >>>>> >>>>> persistence, > >>>>> >>>>> war and ear configurations etc. Basically everything you do as of > >>>>> >>>>> today with > >>>>> >>>>> some kind of XML file, or annotation. Hereby enabling more > >>>>> >>>>> flexibility into > >>>>> >>>>> the existing descriptors is relatively easy, but as mentioned by > >>>>> >>>>> Mark, > >>>>> >>>>> constraint. Adding more flexibility raises other subtle problems. > >>>>> >>>>> Imagine a > >>>>> >>>>> application module, e.g. a war, that defines everything it > >>>>> >>>>> requires. There > >>>>> >>>>> is no need to configure anything more on server side (with spring > >>>>> >>>>> you can do > >>>>> >>>>> this, with Java EE unfortunately not). But this has a severe > >>>>> >>>>> consequence, it > >>>>> >>>>> would make the application really portable in the sense, that it > >>>>> >>>>> can be > >>>>> >>>>> moved between different app servers (vendors) without any change > >>>>> >>>>> (ideally). > >>>>> >>>>> As a result commercial profits of some vendor companies may be > >>>>> >>>>> affected. I > >>>>> >>>>> think this is actually one of the key points, why things are > >>>>> >>>>> getting so > >>>>> >>>>> complicated in that area. > >>>>> >>>>> > >>>>> >>>>> Legal aspects also were discussed. One of them is a possible > >>>>> >>>>> legal > >>>>> >>>>> clash of ALv2 with GPL. This is the case already within > >>>>> >>>>> Glassfish, but one > >>>>> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal > >>>>> >>>>> department. At > >>>>> >>>>> the end we decided to use a BSD model. Even dual licensing > >>>>> >>>>> BSD/ALv2 could > >>>>> >>>>> theoretically be an option. If you would choose ALv2, Oracle will > >>>>> >>>>> not > >>>>> >>>>> include your RI into Glassfish, which is the RI for the EE > >>>>> >>>>> Umbrella JSR, > >>>>> >>>>> meaning your JSR will not be included into EE8. So what should we > >>>>> >>>>> do? I > >>>>> >>>>> don't have a good answer... > >>>>> >>>>> > >>>>> >>>>> So, I like to discuss configuration aspects here. Nevertheless if > >>>>> >>>>> we > >>>>> >>>>> decide to add config aspects, be aware that we might only > >>>>> >>>>> (mainly) support > >>>>> >>>>> application config, since everything else directly would impact > >>>>> >>>>> other JSRs. > >>>>> >>>>> And that is obviously quite similar to what Apache Deltaspike is > >>>>> >>>>> all about > >>>>> >>>>> ;-) > >>>>> >>>>> > >>>>> >>>>> Cheers, > >>>>> >>>>> Anatole > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg >: > >>>>> >>>>>> > >>>>> >>>>>> Yes, the config group also was (obviously) looking at > >>>>> >>>>>> DeltaSpikes > >>>>> >>>>>> config mechanism as well. > >>>>> >>>>>> There were others who wanted to go more into the 'filtering' > >>>>> >>>>>> approach > >>>>> >>>>>> as done on WebLogic servers (though not sure who else does that > >>>>> >>>>>> as well). > >>>>> >>>>>> You know, having all the XML configs like WEB-INF/web.xml > >>>>> >>>>>> containing > >>>>> >>>>>> placeholders and the real values only get placed in there at > >>>>> >>>>>> deployment > >>>>> >>>>>> time. I personally find this approach a bit limited from a > >>>>> >>>>>> technical > >>>>> >>>>>> perspective and it already didn't work out for me when using > >>>>> >>>>>> WebLogic (what > >>>>> >>>>>> about changing a configured value after the deployment was done? > >>>>> >>>>>> What about > >>>>> >>>>>> security? Having passwords in web.xml, unit testing, ...). > >>>>> >>>>>> There are of course also other approaches which all might have > >>>>> >>>>>> strong > >>>>> >>>>>> sides and would have needed to get discussed. > >>>>> >>>>>> > >>>>> >>>>>> But utterly the problem seems to have been legal reasons. We > >>>>> >>>>>> even > >>>>> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF > >>>>> >>>>>> project with > >>>>> >>>>>> substantial support and participation from the JBoss, DeltaSpike > >>>>> >>>>>> and TomEE > >>>>> >>>>>> communities. > >>>>> >>>>>> > >>>>> >>>>>> Anyway, the time will come when we will resurrect this effort. > >>>>> >>>>>> > >>>>> >>>>>> LieGrue, > >>>>> >>>>>> strub > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil > >>>>> >>>>>> > wrote: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> Yep, it contains a simple but extendable notion of ProjectStage, > >>>>> >>>>>> too;-) > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament > >>>>> >>>>>> > > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> Anatole, > >>>>> >>>>>> > >>>>> >>>>>> I'm wondering if some of your configuration description falls > >>>>> >>>>>> under > >>>>> >>>>>> what was put together in DeltaSpike? > >>>>> >>>>>> > >>>>> >>>>>> http://deltaspike.apache.org/configuration.html > >>>>> >>>>>> > >>>>> >>>>>> John > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch > >>>>> >>>>>> > > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> Staging is not a question of xml or not xml (the "format" of > >>>>> >>>>>> config). > >>>>> >>>>>> You can do staged config also using xml, or based on a database > >>>>> >>>>>> or json > >>>>> >>>>>> config service. Staging as well as, more generally speaking, > >>>>> >>>>>> environment > >>>>> >>>>>> dependent config is more like to select/filter the right config > >>>>> >>>>>> that targets > >>>>> >>>>>> the current (runtime) environment. This might include stages, > >>>>> >>>>>> but also many > >>>>> >>>>>> other aspects are feasible and common (server, tier, ear, war, > >>>>> >>>>>> tenant ...). > >>>>> >>>>>> Since these aspects are per se very complex, it might be > >>>>> >>>>>> advisable to leave > >>>>> >>>>>> them out of any spec (even a dedicated config JSR would probably > >>>>> >>>>>> not be > >>>>> >>>>>> capable of covering these within the relatively short EE > >>>>> >>>>>> timeframe)... > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil >: > >>>>> >>>>>> > >>>>> >>>>>> Jens/all, > >>>>> >>>>>> > >>>>> >>>>>> A sort of "staging" already was possible using CDI earlier, see > >>>>> >>>>>> examples like this: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war > >>>>> >>>>>> > >>>>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond the > >>>>> >>>>>> primitive, hard-coded JSF enum. > >>>>> >>>>>> > >>>>> >>>>>> If that works without XML, while still allowing flexible > >>>>> >>>>>> configuration > >>>>> >>>>>> for different stages or to add and "inject" additional stages > >>>>> >>>>>> maybe even on > >>>>> >>>>>> a tenant basis (for Cloud scenarios) I could see something like > >>>>> >>>>>> that work > >>>>> >>>>>> without XML. In the Multiconf project we managed to code > >>>>> >>>>>> everything in > >>>>> >>>>>> Python, and similar to Puppet or Chef you can configure and > >>>>> >>>>>> deploy multiple > >>>>> >>>>>> environments with it, Java EE, Spring or Play! several of them > >>>>> >>>>>> are > >>>>> >>>>>> configured this way and it requires no XML (where the container > >>>>> >>>>>> needs such > >>>>> >>>>>> files, the framework generates them;-) > >>>>> >>>>>> > >>>>> >>>>>> Werner > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, > >>>>> >>>>>> > > >>>>> >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole > >>>>> >>>>>> Tresch) > >>>>> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) > >>>>> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition > >>>>> >>>>>> (Anatole Tresch (JIRA)) > >>>>> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) > >>>>> >>>>>> > >>>>> >>>>>> ------------------------------ > >>>>> >>>>>> > >>>>> >>>>>> Message: 4 > >>>>> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 > >>>>> >>>>>> From: Jens Schumann > > >>>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... > >>>>> >>>>>> To: Anatole Tresch >, Antonio Goncalves > >>>>> >>>>>> > > >>>>> >>>>>> Cc: cdi-dev > > >>>>> >>>>>> Message-ID: > > >>>>> >>>>>> Content-Type: text/plain; charset="windows-1252" > >>>>> >>>>>> > >>>>> >>>>>> I can confirm that this approach works very well. We are using a > >>>>> >>>>>> similar approach a couple of years now, and I love the > >>>>> >>>>>> simplicity that comes > >>>>> >>>>>> with portable extensions and @Producer methods. See our public > >>>>> >>>>>> version here > >>>>> >>>>>> [1] (works since early CDI 1.0 days) . > >>>>> >>>>>> > >>>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier > >>>>> >>>>>> @Property. > >>>>> >>>>>> We support default values and type conversation for primitives > >>>>> >>>>>> and > >>>>> >>>>>> everything that has a string based constructor. The property > >>>>> >>>>>> source can be > >>>>> >>>>>> anything, from property files (default) to databases or xml > >>>>> >>>>>> files. For > >>>>> >>>>>> examples see tests here [2]. > >>>>> >>>>>> > >>>>> >>>>>> Nevertheless I am not sure if this should be part of an future > >>>>> >>>>>> CDI > >>>>> >>>>>> spec. My concerns include the bloat argument, of course. But the > >>>>> >>>>>> main reason > >>>>> >>>>>> relates to the fact that we have almost everything in the > >>>>> >>>>>> current CDI spec > >>>>> >>>>>> already. > >>>>> >>>>>> > >>>>> >>>>>> Right now I am quite happy with an custom portable extension > >>>>> >>>>>> that does > >>>>> >>>>>> everything for me. At the time we implemented the extension we > >>>>> >>>>>> realised that > >>>>> >>>>>> the "hard part" was writing an extension that links a qualified > >>>>> >>>>>> "optional > >>>>> >>>>>> injection point" with an @Producer method while supporting code > >>>>> >>>>>> based > >>>>> >>>>>> default values. Luckily I had Arne in my team who did that > >>>>> >>>>>> within a few > >>>>> >>>>>> minutes. > >>>>> >>>>>> > >>>>> >>>>>> Because of this experience I would propose that we simplify > >>>>> >>>>>> extension > >>>>> >>>>>> development such that "optional injection points" may be linked > >>>>> >>>>>> to @Produces > >>>>> >>>>>> values easily. Additionally we have to solve a few more > >>>>> >>>>>> integration issues > >>>>> >>>>>> (e.g. read-only DB access should be available during CDI > >>>>> >>>>>> startup). > >>>>> >>>>>> Everything else should be provided by portable extensions (e.g. > >>>>> >>>>>> via > >>>>> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org . > >>>>> >>>>>> > >>>>> >>>>>> Jens > >>>>> >>>>>> [1] > >>>>> >>>>>> > >>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property > >>>>> >>>>>> [2] > >>>>> >>>>>> > >>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property > >>>>> >>>>>> > >>>>> >>>>>> Von: Anatole Tresch > >>>>> >>>>>> >> > >>>>> >>>>>> Datum: Friday 5 September 2014 21:22 > >>>>> >>>>>> An: Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> >> > >>>>> >>>>>> Cc: CDI-Dev > >>>>> >>>>>> >> > >>>>> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... > >>>>> >>>>>> > >>>>> >>>>>> Hi all, > >>>>> >>>>>> > >>>>> >>>>>> I would not like to add an XML "bloated" mechanism as part of > >>>>> >>>>>> CDI 2.0. > >>>>> >>>>>> Spontaneously I would propose a more CDI like things like: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> * Adding a @Configured annotation (basically a qualifier). > >>>>> >>>>>> This > >>>>> >>>>>> can be in addition to @Inject and would allow to inject > >>>>> >>>>>> "configured" values. > >>>>> >>>>>> * Since configuration can change we may think of a (CDI) > >>>>> >>>>>> event/reinject mechanism based on config changes. By default, > >>>>> >>>>>> this is > >>>>> >>>>>> switched off and we can discuss how it would be activated, e.g. > >>>>> >>>>>> by an > >>>>> >>>>>> additional flag settable with the @Configured annotation, or an > >>>>> >>>>>> additional > >>>>> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon > >>>>> >>>>>> framework), or both. > >>>>> >>>>>> * Hereby configured values theoretically behave similar as > >>>>> >>>>>> all > >>>>> >>>>>> other injection points. They also can be qualified (the aspect > >>>>> >>>>>> of scopes, I > >>>>> >>>>>> did not yet have time to think about). The only difference is, > >>>>> >>>>>> that they are > >>>>> >>>>>> satisified using the configuration "system". > >>>>> >>>>>> * The configuration "source" itself could in the extreme > >>>>> >>>>>> simplest > >>>>> >>>>>> way be a Provider>. The CDI spec should not > >>>>> >>>>>> care about > >>>>> >>>>>> how this map is provided (XML, DB, overrides, etc). This still > >>>>> >>>>>> can be > >>>>> >>>>>> standardized later. As long as the ConfigurationSource SPI is > >>>>> >>>>>> defined, > >>>>> >>>>>> companies still can hook in the logic and level of configuration > >>>>> >>>>>> abstraction > >>>>> >>>>>> they need. > >>>>> >>>>>> * Of course, since not only Strings can be injected, we need > >>>>> >>>>>> some > >>>>> >>>>>> conversion or adapter logic as basically outlined in my blog. > >>>>> >>>>>> Also here we > >>>>> >>>>>> can add a simple SPI and let the details to the RI. > >>>>> >>>>>> > >>>>> >>>>>> Summarizing a > >>>>> >>>>>> > >>>>> >>>>>> * @Configured annotation > >>>>> >>>>>> * some kind of change event > >>>>> >>>>>> * a ConfigurationSource extends Provider> > >>>>> >>>>>> * a conversion mechanism from String to T. > >>>>> >>>>>> > >>>>> >>>>>> we get a full fledged configuration mechanism that leverages > >>>>> >>>>>> CDI. > >>>>> >>>>>> > >>>>> >>>>>> That would be my idea basically. WDYT? I will try to work that > >>>>> >>>>>> out in > >>>>> >>>>>> more details. Basically it should be implementable even with the > >>>>> >>>>>> CDI > >>>>> >>>>>> mechanism already in place with CDI 1.1. > >>>>> >>>>>> > >>>>> >>>>>> Best, > >>>>> >>>>>> Anatole > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> >>: > >>>>> >>>>>> One wise man* once said "EJB was a hype specification, we added > >>>>> >>>>>> too > >>>>> >>>>>> many things to it, it became bloated. The next hype > >>>>> >>>>>> specifications are > >>>>> >>>>>> JAX-RS and CDI, careful with them" > >>>>> >>>>>> > >>>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup > >>>>> >>>>>> being > >>>>> >>>>>> bloated. > >>>>> >>>>>> > >>>>> >>>>>> Antonio > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> *David Blevin > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand > >>>>> >>>>>> >> > >>>>> >>>>>> wrote: > >>>>> >>>>>> Hi all, > >>>>> >>>>>> > >>>>> >>>>>> You may have followed the rise and fall of the Java Config JSR > >>>>> >>>>>> > >>>>> >>>>>> (http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html ). > >>>>> >>>>>> Anatole in CC was leading this initiative and I proposed him to > >>>>> >>>>>> join > >>>>> >>>>>> us and explore if some part of his late-JSR could be done in > >>>>> >>>>>> CDI. > >>>>> >>>>>> > >>>>> >>>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 > >>>>> >>>>>> or > >>>>> >>>>>> related solution. If we achieve to have a majority of specs to > >>>>> >>>>>> integrate > >>>>> >>>>>> with CDI, our configuration solution would therefore become a > >>>>> >>>>>> configuration > >>>>> >>>>>> system for all spec based on CDI 2.0. > >>>>> >>>>>> > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Antonio Goncalves > >>>>> >>>>>> Software architect, Java Champion and Pluralsight author > >>>>> >>>>>> > >>>>> >>>>>> Web site> | > >>>>> >>>>>> Twitter> | > >>>>> >>>>>> LinkedIn> | > >>>>> >>>>>> > >>>>> >>>>>> Pluralsight> > >>>>> >>>>>> | Paris JUG> | Devoxx > >>>>> >>>>>> France> > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Anatole Tresch > >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>>> Gl?rnischweg 10 > >>>>> >>>>>> CH - 8620 Wetzikon > >>>>> >>>>>> > >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>>> Twitter: @atsticks > >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>>> Google: atsticks > >>>>> >>>>>> Mobile +41-76 344 62 79 > >>>>> >>>>>> -------------- next part -------------- > >>>>> >>>>>> An HTML attachment was scrubbed... > >>>>> >>>>>> URL: > >>>>> >>>>>> > >>>>> >>>>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 > >>>>> >>>>>> *************************************** > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Anatole Tresch > >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>>> Gl?rnischweg 10 > >>>>> >>>>>> CH - 8620 Wetzikon > >>>>> >>>>>> > >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>>> Twitter: @atsticks > >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>>> Google: atsticks > >>>>> >>>>>> Mobile +41-76 344 62 79 > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> -- > >>>>> >>>>> Anatole Tresch > >>>>> >>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>> Gl?rnischweg 10 > >>>>> >>>>> CH - 8620 Wetzikon > >>>>> >>>>> > >>>>> >>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>> Twitter: @atsticks > >>>>> >>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>> Google: atsticks > >>>>> >>>>> Mobile +41-76 344 62 79 > >>>>> >>>> > >>>>> >>>> > >>>>> >>> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> -- > >>>>> >> Anatole Tresch > >>>>> >> Java Lead Engineer, JSR Spec Lead > >>>>> >> Gl?rnischweg 10 > >>>>> >> CH - 8620 Wetzikon > >>>>> >> > >>>>> >> Switzerland, Europe Zurich, GMT+1 > >>>>> >> Twitter: @atsticks > >>>>> >> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >> Google: atsticks > >>>>> >> Mobile +41-76 344 62 79 > >>>>> > > >>>>> > > >>>>> > > >>>>> > _______________________________________________ > >>>>> > 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. > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Anatole Tresch > >>>> Java Lead Engineer, JSR Spec Lead > >>>> Gl?rnischweg 10 > >>>> CH - 8620 Wetzikon > >>>> > >>>> Switzerland, Europe Zurich, GMT+1 > >>>> Twitter: @atsticks > >>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>> Google: atsticks > >>>> Mobile +41-76 344 62 79 > >>> > >>> > >>> _______________________________________________ > >>> 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. > >> > >> > >> > >> > >> -- > >> Antonio Goncalves > >> Software architect, Java Champion and Pluralsight author > >> > >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France _______________________________________________ > 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/20140908/e905720a/attachment-0001.html From atsticks at gmail.com Mon Sep 8 15:35:33 2014 From: atsticks at gmail.com (Anatole Tresch) Date: Mon, 8 Sep 2014 21:35:33 +0200 Subject: [cdi-dev] Java Config and CDI - A Minimal Outline Message-ID: Therefore we should probably think of - ensure we have hooks in CDI 2, where we can put the config mechanism into to configure (control?) CDI itself. All the rest can be done by just deploying and activating a CDI extension. I will write a blog on that soon (it is already working here on my machine with CDI 1.2 ;-) ). Then we should try getting a SE JSR up and running (let us discuss that during J1 and at the next EC meeting) to define how we define, assemble and manage config in general. CDI then is only one of multiple possible consumers. -Anatole 2014-09-08 17:20 GMT+02:00 Mark Struberg : > Antonio, the problem is that the config mechanism would need to be plain > old java. In the best case even without classpath scanning. > We need it during the boot time of the container (CDI and all other EE > components boot time) so we cannot use CDI mechanics. > > If you look at DeltaSpike you will see that ConfigResolver just uses plain > static methods. This is the only way we can use the config mechanism during > boot time, e.g. to exclude classes in ProcessAnnotatedType, etc. > > The CDI part are only a few producers on top of it. We really need some > common ground for configuration, but I don't think the CDI spec is the > place where it should be handled... > > LieGrue, > strub > > > > On Monday, 8 September 2014, 15:32, Antonio Goncalves < > antonio.goncalves at gmail.com> wrote: > > > > It's just a matter of knowing what we want to do : > > * Add configuration into CDI 2.0 : it goes into the spec > * Forget about configuration : it goes nowhere > * Give configuration a chance for later : start the brainstorming, define > an API, make sure it works with CDI 2.0... and leave the work in the > appendix so the Java EE 9 expert group can read it and decide if they > should take it or not. Appendixe is just a way of saying "we've deeply > thought about it, this is the way we think it should be done, now the > future EG decides" > > Antonio > > On Mon, Sep 8, 2014 at 11:51 AM, Romain Manni-Bucau > wrote: > > @Antonio: -1 for an appendix, bean validation is the example it is > broken. Idea is awesome, everybody liked it so it was added -> great. > Here everybody already agrees it is good so no need of "staging" phase > IMHO. BV appendix was not the API used so it broke apps using it. SO > using proprietary stuff is the same, it basically mean an appendix > spec for something not under discussion (regarding its need) is IMHO > useless. > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > 2014-09-08 10:29 GMT+02:00 Werner Keil : > > Hi, > > > > If it's not really usable as API or annotation I don't see much value in > > adding some "how to" or intent for the future into the Spec Document. > > > > If it was to become a part of CDI 2, there's nothing against optionality > > like MEEP 8 or JSR 363 already practice on the SE/EE side either. > > > > Agorava/DeltaSpike demonstrate how true modularity work, similar to the > JSRs > > mentioned above, where you have multiple module JARs/bundles instead of a > > big monolithic one. Some JSRs like Batch also declared separate > "annotation" > > modules, so that's what CDI 2 should also do if it was a feature Inside > of > > it. > > Calling some features optional if they're not used by every > implementation > > allows them to chose. That was also the main value of keeping @Inject a > > separate "module" under CDI. It was never included into a JDK but used > > independently. > > > > The core of a Config module would ideally work in SE, but CDI 2 already > > declared an aim to have some modules work under SE. > > > > Werner > > > > Am 08.09.2014 09:47 schrieb "Antonio Goncalves" > > : > > > >> Hi all, > >> > >> I really have some concerns about adding configuration into CDI but I > can > >> see benefits too. And what about adding it... and not adding it at the > same > >> time ? In Bean Validation 1.0, the Expert Group decided not to include > >> method-level validation in the spec (it was included in 1.1). But what > they > >> did is to add it as a proposal in the Appendix. > >> > >> If we feel some configuration should get in, why not have a proposal in > >> the Appendix of CDI 2.0 ? It could then be implemented by Weld (and > >> OpenWebBeans if they feel like it). And then, if it's successful and > things > >> get easier, get its own JSR for Java EE 9. > >> > >> WDYT ? > >> > >> Antonio > >> > >> On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau < > rmannibucau at gmail.com> > >> wrote: > >>> > >>> Hmm > >>> > >>> I see config jsr as a jse spec which would allow EE injections in > config > >>> components in EE containers (exactly like jbatch). > >>> > >>> This way it can be used without any container or with any container > >>> easily. Only limit will be to not do something cdi/known containers > will not > >>> support I think. > >>> > >>> Not sure EE side is needed today, a lot can already be done without it > >>> and it can be enhanced later adding some integration words. > >>> > >>> Le 8 sept. 2014 00:01, "Anatole Tresch" a ?crit : > >>> > >>>> Hi Romain > >>>> > >>>> just a few remarks inline... > >>>> > >>>> Summarizing > >>>> 1) injection of values, reinjection, feedback on config changes can > all > >>>> be done with already existing features (producers, extensions). > >>>> 2) configuring/bootstrapping CDI itself, e.g. configuration, is > targeted > >>>> with CDI 2.0 (see spec failing) > >>>> > >>>> So basically we could try to look if there is enough interest to > >>>> standardize configuration in a more general way. For deployment > aspects we > >>>> need an EE JSR, for the rest, another SE standard may be an option as > >>>> well... tbd... > >>>> > >>>> -Anatole > >>>> > >>>> > >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : > >>>>> > >>>>> well sorry to pop in so late but here are my 2cts > >>>> > >>>> easy ;) > >>>> > >>>>> > >>>>> Config JSR is more about environment config IMHO and putting it in > CDI > >>>>> doesn't make sense since more or more spec works without any other > >>>>> spec - CDI in our case. > >>>> > >>>> CDI even with some config mechanism added would still work > "standalone". > >>>> > >>>> > >>>>> > >>>>> This mean CDI can't be the place but should > >>>>> just be the bridge for config JSR. > >>>> > >>>> As I suggested as well. > >>>> > >>>> > >>>>> > >>>>> Plus CDI config will surely highly > >>>>> be an application config first (beans.xml should be the place then) > >>>> > >>>> Yes, app config, but beware people of writing config into beans.xml. > >>>> That is definitively in most cases not what you want. CDI should not > define, > >>>> where and how config is located and formatted. CDI should provide a > SPI, > >>>> where config providers can publish the configured values, so it can be > >>>> injected wherever needed. E.g. some kind of producer, that can provide > >>>> multiple objects to be injected and can benefit from some kind of > callback > >>>> mechanism would be sufficient... > >>>> > >>>>> > >>>>> then environment config can be done at EE level (saying it has to > >>>>> support placeholders or any pre deployment processing). > >>>> > >>>> Config is much more complex. There is no clear border what is > >>>> environment config or environment dependent and what not. This > depends on > >>>> what kind of application you have deployed. As an example the email > address, > >>>> where you send error messages, can be different depenending on the > >>>> stage/environment, but this is not EE related config entry. Also what > an > >>>> environment is, is not a thing that you can define completely. So I > agree > >>>> not to add this complexities to CDI, I would hide them between some > kind of > >>>> "config provider", as mentioned above. CDI does not need to know if > the > >>>> config provided is environment dependent or not, its just what is > visible at > >>>> a current runtime state... > >>>> > >>>>> > >>>>> If you put something like ProjectStage in CDI it is great but then > you > >>>>> have it in JSF, CDI and finally surely all specs...same as > >>>>> converters... > >>>> > >>>> That was originally the idea, when doing a EE config JSR, but without > >>>> such standard. I agree, CDI is not the place to define them. > >>>> > >>>> > >>>>> > >>>>> Config should really be split in: > >>>>> 1) spec dependent config -> spec.xml > >>>>> 2) *common* config (a bit like javax.annotation) for environment and > >>>>> external configuration -> Config JSR > >>>> > >>>> Not 100% sure, if a get the point here... > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau : > >>>>> > >>>>> well sorry to pop in so late but here are my 2cts > >>>>> > >>>>> Config JSR is more about environment config IMHO and putting it in > CDI > >>>>> doesn't make sense since more or more spec works without any other > >>>>> spec - CDI in our case. This mean CDI can't be the place but should > >>>>> just be the bridge for config JSR. Plus CDI config will surely highly > >>>>> be an application config first (beans.xml should be the place then) > >>>>> then environment config can be done at EE level (saying it has to > >>>>> support placeholders or any pre deployment processing). > >>>>> > >>>>> If you put something like ProjectStage in CDI it is great but then > you > >>>>> have it in JSF, CDI and finally surely all specs...same as > >>>>> converters... > >>>>> > >>>>> Config should really be split in: > >>>>> 1) spec dependent config -> spec.xml > >>>>> 2) *common* config (a bit like javax.annotation) for environment and > >>>>> external configuration -> Config JSR > >>>>> > >>>>> wdyt? > >>>>> > >>>>> > >>>>> > >>>>> Romain Manni-Bucau > >>>>> Twitter: @rmannibucau > >>>>> Blog: http://rmannibucau.wordpress.com/ > >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau > >>>>> Github: https://github.com/rmannibucau > >>>>> > >>>>> > >>>>> 2014-09-07 23:39 GMT+02:00 Werner Keil : > >>>>> > Sounds like an argument for a CDI module rather than a separate JSR > >>>>> > then?;-) > >>>>> > > >>>>> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch < > atsticks at gmail.com> > >>>>> > wrote: > >>>>> >> > >>>>> >> I would not worry about CDI regarding licensing. Just the sentence > >>>>> >> was > >>>>> >> that Oracle does not want to have more ALv2 in addition to what is > >>>>> >> already > >>>>> >> there. So as long as we do things within CDI, no worries, I think. > >>>>> >> For new > >>>>> >> EE JSRs nevertheless this is a BIG issue and should be clarified > by > >>>>> >> the EC! > >>>>> >> > >>>>> >> > >>>>> >> 2014-09-07 21:44 GMT+02:00 Werner Keil : > >>>>> >>> > >>>>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec > under > >>>>> >>> ALv2 > >>>>> >>> as a dual-license, this was discussed by EC Members but both JCP > EC > >>>>> >>> and > >>>>> >>> Oracle Legal/PMO seems fine with it, and CDI is already an > >>>>> >>> essential > >>>>> >>> building block to Java EE 6/7, hence used with Glassfish, too. I > >>>>> >>> wasn't > >>>>> >>> involved in these discussions, but given CDI is especially > liberal > >>>>> >>> and fully > >>>>> >>> accepted by JCP formalities and license policies, I don't really > >>>>> >>> see what > >>>>> >>> the problem wss for Anatole's JSR attempt (though I know, both > >>>>> >>> Oracle and > >>>>> >>> other EC Members/companies don't always prefer this kind of > >>>>> >>> licensing...;-) > >>>>> >>> > >>>>> >>> Werner > >>>>> >>> > >>>>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament > >>>>> >>> > >>>>> >>> wrote: > >>>>> >>>> > >>>>> >>>> Ok, this mail has me more concerned than anything. Can you > >>>>> >>>> clarify this > >>>>> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. > >>>>> >>>> > >>>>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch > >>>>> >>>> > >>>>> >>>> wrote: > >>>>> >>>>> > >>>>> >>>>> Hi All > >>>>> >>>>> > >>>>> >>>>> unfortunately things seem quite complicated: > >>>>> >>>>> > >>>>> >>>>> first of all, similarities with Deltaspike are basically not > >>>>> >>>>> accidental. The concepts we developed in Credit Suisse are very > >>>>> >>>>> similar to > >>>>> >>>>> Deltaspike, though Deltaspike was not yet born at that time. > >>>>> >>>>> Fortunately we > >>>>> >>>>> ended up with a similar kind of solution. > >>>>> >>>>> filtering still can be done. My idea is to define some kind of > >>>>> >>>>> "configuration provider", which then is dynamically asked for > >>>>> >>>>> configuration. > >>>>> >>>>> How the provider is internally organized, is completely > >>>>> >>>>> transparent to CDI. > >>>>> >>>>> This enables to have multi-layered, complex config solutions > work > >>>>> >>>>> the same > >>>>> >>>>> (from a view point of CDI) like simple programmatic test > >>>>> >>>>> configurations > >>>>> >>>>> during unit tests. The config provider still can support > >>>>> >>>>> filtering and > >>>>> >>>>> dynamic resolution as commonly used in configuration systems. > >>>>> >>>>> Similarly the > >>>>> >>>>> format is basically also not fixed. Of course, would a > reference > >>>>> >>>>> implementation provide a set of functionalities, but I would > >>>>> >>>>> definitively > >>>>> >>>>> not define the exact configuration mechanism as part of the CDI > >>>>> >>>>> (or even a > >>>>> >>>>> EE config JSR). Another reason, beside complexity and time, is > >>>>> >>>>> the fact that > >>>>> >>>>> different companies handle, store and manage configuration > >>>>> >>>>> differently, so a > >>>>> >>>>> mechanism must be flexible enough to accommodate these, without > >>>>> >>>>> adoption > >>>>> >>>>> rate will be low. Furthermore this flexibility also keeps doors > >>>>> >>>>> open for use > >>>>> >>>>> cases we do not know yet. > >>>>> >>>>> Also we have to separate some basically two types of > >>>>> >>>>> configuration > >>>>> >>>>> aspects: > >>>>> >>>>> > >>>>> >>>>> application config basically is injected into deployed > >>>>> >>>>> components, but > >>>>> >>>>> basically only can affect deployment to the extend it can be > >>>>> >>>>> managed and > >>>>> >>>>> injected by CDI. The basic architecture and design, how > >>>>> >>>>> application servers > >>>>> >>>>> to load and deploy are basically not affected. This type of > >>>>> >>>>> configuration > >>>>> >>>>> (mechanism) I see also as a possible addition to CDI, if we > >>>>> >>>>> really fail to > >>>>> >>>>> do something in another JSR. With CDI going for a more modular > >>>>> >>>>> design, even > >>>>> >>>>> basic configuration of CDI can be possible, given we have some > >>>>> >>>>> kind of API, > >>>>> >>>>> we can access during CDI initialization. > >>>>> >>>>> On the other side deployment configuration affects directly how > >>>>> >>>>> the > >>>>> >>>>> application server deploys the application. Configuration here > >>>>> >>>>> would allow > >>>>> >>>>> to define datasources, EJBs, transactional aspects, security, > >>>>> >>>>> persistence, > >>>>> >>>>> war and ear configurations etc. Basically everything you do as > of > >>>>> >>>>> today with > >>>>> >>>>> some kind of XML file, or annotation. Hereby enabling more > >>>>> >>>>> flexibility into > >>>>> >>>>> the existing descriptors is relatively easy, but as mentioned > by > >>>>> >>>>> Mark, > >>>>> >>>>> constraint. Adding more flexibility raises other subtle > problems. > >>>>> >>>>> Imagine a > >>>>> >>>>> application module, e.g. a war, that defines everything it > >>>>> >>>>> requires. There > >>>>> >>>>> is no need to configure anything more on server side (with > spring > >>>>> >>>>> you can do > >>>>> >>>>> this, with Java EE unfortunately not). But this has a severe > >>>>> >>>>> consequence, it > >>>>> >>>>> would make the application really portable in the sense, that > it > >>>>> >>>>> can be > >>>>> >>>>> moved between different app servers (vendors) without any > change > >>>>> >>>>> (ideally). > >>>>> >>>>> As a result commercial profits of some vendor companies may be > >>>>> >>>>> affected. I > >>>>> >>>>> think this is actually one of the key points, why things are > >>>>> >>>>> getting so > >>>>> >>>>> complicated in that area. > >>>>> >>>>> > >>>>> >>>>> Legal aspects also were discussed. One of them is a possible > >>>>> >>>>> legal > >>>>> >>>>> clash of ALv2 with GPL. This is the case already within > >>>>> >>>>> Glassfish, but one > >>>>> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal > >>>>> >>>>> department. At > >>>>> >>>>> the end we decided to use a BSD model. Even dual licensing > >>>>> >>>>> BSD/ALv2 could > >>>>> >>>>> theoretically be an option. If you would choose ALv2, Oracle > will > >>>>> >>>>> not > >>>>> >>>>> include your RI into Glassfish, which is the RI for the EE > >>>>> >>>>> Umbrella JSR, > >>>>> >>>>> meaning your JSR will not be included into EE8. So what should > we > >>>>> >>>>> do? I > >>>>> >>>>> don't have a good answer... > >>>>> >>>>> > >>>>> >>>>> So, I like to discuss configuration aspects here. Nevertheless > if > >>>>> >>>>> we > >>>>> >>>>> decide to add config aspects, be aware that we might only > >>>>> >>>>> (mainly) support > >>>>> >>>>> application config, since everything else directly would impact > >>>>> >>>>> other JSRs. > >>>>> >>>>> And that is obviously quite similar to what Apache Deltaspike > is > >>>>> >>>>> all about > >>>>> >>>>> ;-) > >>>>> >>>>> > >>>>> >>>>> Cheers, > >>>>> >>>>> Anatole > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : > >>>>> >>>>>> > >>>>> >>>>>> Yes, the config group also was (obviously) looking at > >>>>> >>>>>> DeltaSpikes > >>>>> >>>>>> config mechanism as well. > >>>>> >>>>>> There were others who wanted to go more into the 'filtering' > >>>>> >>>>>> approach > >>>>> >>>>>> as done on WebLogic servers (though not sure who else does > that > >>>>> >>>>>> as well). > >>>>> >>>>>> You know, having all the XML configs like WEB-INF/web.xml > >>>>> >>>>>> containing > >>>>> >>>>>> placeholders and the real values only get placed in there at > >>>>> >>>>>> deployment > >>>>> >>>>>> time. I personally find this approach a bit limited from a > >>>>> >>>>>> technical > >>>>> >>>>>> perspective and it already didn't work out for me when using > >>>>> >>>>>> WebLogic (what > >>>>> >>>>>> about changing a configured value after the deployment was > done? > >>>>> >>>>>> What about > >>>>> >>>>>> security? Having passwords in web.xml, unit testing, ...). > >>>>> >>>>>> There are of course also other approaches which all might have > >>>>> >>>>>> strong > >>>>> >>>>>> sides and would have needed to get discussed. > >>>>> >>>>>> > >>>>> >>>>>> But utterly the problem seems to have been legal reasons. We > >>>>> >>>>>> even > >>>>> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF > >>>>> >>>>>> project with > >>>>> >>>>>> substantial support and participation from the JBoss, > DeltaSpike > >>>>> >>>>>> and TomEE > >>>>> >>>>>> communities. > >>>>> >>>>>> > >>>>> >>>>>> Anyway, the time will come when we will resurrect this effort. > >>>>> >>>>>> > >>>>> >>>>>> LieGrue, > >>>>> >>>>>> strub > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> Yep, it contains a simple but extendable notion of > ProjectStage, > >>>>> >>>>>> too;-) > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament > >>>>> >>>>>> > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> Anatole, > >>>>> >>>>>> > >>>>> >>>>>> I'm wondering if some of your configuration description falls > >>>>> >>>>>> under > >>>>> >>>>>> what was put together in DeltaSpike? > >>>>> >>>>>> > >>>>> >>>>>> http://deltaspike.apache.org/configuration.html > >>>>> >>>>>> > >>>>> >>>>>> John > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch > >>>>> >>>>>> > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> Staging is not a question of xml or not xml (the "format" of > >>>>> >>>>>> config). > >>>>> >>>>>> You can do staged config also using xml, or based on a > database > >>>>> >>>>>> or json > >>>>> >>>>>> config service. Staging as well as, more generally speaking, > >>>>> >>>>>> environment > >>>>> >>>>>> dependent config is more like to select/filter the right > config > >>>>> >>>>>> that targets > >>>>> >>>>>> the current (runtime) environment. This might include stages, > >>>>> >>>>>> but also many > >>>>> >>>>>> other aspects are feasible and common (server, tier, ear, war, > >>>>> >>>>>> tenant ...). > >>>>> >>>>>> Since these aspects are per se very complex, it might be > >>>>> >>>>>> advisable to leave > >>>>> >>>>>> them out of any spec (even a dedicated config JSR would > probably > >>>>> >>>>>> not be > >>>>> >>>>>> capable of covering these within the relatively short EE > >>>>> >>>>>> timeframe)... > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil >: > >>>>> >>>>>> > >>>>> >>>>>> Jens/all, > >>>>> >>>>>> > >>>>> >>>>>> A sort of "staging" already was possible using CDI earlier, > see > >>>>> >>>>>> examples like this: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war > >>>>> >>>>>> > >>>>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond > the > >>>>> >>>>>> primitive, hard-coded JSF enum. > >>>>> >>>>>> > >>>>> >>>>>> If that works without XML, while still allowing flexible > >>>>> >>>>>> configuration > >>>>> >>>>>> for different stages or to add and "inject" additional stages > >>>>> >>>>>> maybe even on > >>>>> >>>>>> a tenant basis (for Cloud scenarios) I could see something > like > >>>>> >>>>>> that work > >>>>> >>>>>> without XML. In the Multiconf project we managed to code > >>>>> >>>>>> everything in > >>>>> >>>>>> Python, and similar to Puppet or Chef you can configure and > >>>>> >>>>>> deploy multiple > >>>>> >>>>>> environments with it, Java EE, Spring or Play! several of them > >>>>> >>>>>> are > >>>>> >>>>>> configured this way and it requires no XML (where the > container > >>>>> >>>>>> needs such > >>>>> >>>>>> files, the framework generates them;-) > >>>>> >>>>>> > >>>>> >>>>>> Werner > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, > >>>>> >>>>>> > >>>>> >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github (Anatole > >>>>> >>>>>> Tresch) > >>>>> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) > >>>>> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() > definition > >>>>> >>>>>> (Anatole Tresch (JIRA)) > >>>>> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) > >>>>> >>>>>> > >>>>> >>>>>> ------------------------------ > >>>>> >>>>>> > >>>>> >>>>>> Message: 4 > >>>>> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 > >>>>> >>>>>> From: Jens Schumann > >>>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... > >>>>> >>>>>> To: Anatole Tresch , Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> Cc: cdi-dev > >>>>> >>>>>> Message-ID: > >>>>> >>>>>> Content-Type: text/plain; charset="windows-1252" > >>>>> >>>>>> > >>>>> >>>>>> I can confirm that this approach works very well. We are > using a > >>>>> >>>>>> similar approach a couple of years now, and I love the > >>>>> >>>>>> simplicity that comes > >>>>> >>>>>> with portable extensions and @Producer methods. See our public > >>>>> >>>>>> version here > >>>>> >>>>>> [1] (works since early CDI 1.0 days) . > >>>>> >>>>>> > >>>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier > >>>>> >>>>>> @Property. > >>>>> >>>>>> We support default values and type conversation for primitives > >>>>> >>>>>> and > >>>>> >>>>>> everything that has a string based constructor. The property > >>>>> >>>>>> source can be > >>>>> >>>>>> anything, from property files (default) to databases or xml > >>>>> >>>>>> files. For > >>>>> >>>>>> examples see tests here [2]. > >>>>> >>>>>> > >>>>> >>>>>> Nevertheless I am not sure if this should be part of an future > >>>>> >>>>>> CDI > >>>>> >>>>>> spec. My concerns include the bloat argument, of course. But > the > >>>>> >>>>>> main reason > >>>>> >>>>>> relates to the fact that we have almost everything in the > >>>>> >>>>>> current CDI spec > >>>>> >>>>>> already. > >>>>> >>>>>> > >>>>> >>>>>> Right now I am quite happy with an custom portable extension > >>>>> >>>>>> that does > >>>>> >>>>>> everything for me. At the time we implemented the extension we > >>>>> >>>>>> realised that > >>>>> >>>>>> the "hard part" was writing an extension that links a > qualified > >>>>> >>>>>> "optional > >>>>> >>>>>> injection point" with an @Producer method while supporting > code > >>>>> >>>>>> based > >>>>> >>>>>> default values. Luckily I had Arne in my team who did that > >>>>> >>>>>> within a few > >>>>> >>>>>> minutes. > >>>>> >>>>>> > >>>>> >>>>>> Because of this experience I would propose that we simplify > >>>>> >>>>>> extension > >>>>> >>>>>> development such that "optional injection points" may be > linked > >>>>> >>>>>> to @Produces > >>>>> >>>>>> values easily. Additionally we have to solve a few more > >>>>> >>>>>> integration issues > >>>>> >>>>>> (e.g. read-only DB access should be available during CDI > >>>>> >>>>>> startup). > >>>>> >>>>>> Everything else should be provided by portable extensions > (e.g. > >>>>> >>>>>> via > >>>>> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. > >>>>> >>>>>> > >>>>> >>>>>> Jens > >>>>> >>>>>> [1] > >>>>> >>>>>> > >>>>> >>>>>> > https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property > >>>>> >>>>>> [2] > >>>>> >>>>>> > >>>>> >>>>>> > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property > >>>>> >>>>>> > >>>>> >>>>>> Von: Anatole Tresch > >>>>> >>>>>> > > >>>>> >>>>>> Datum: Friday 5 September 2014 21:22 > >>>>> >>>>>> An: Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> antonio.goncalves at gmail.com>> > >>>>> >>>>>> Cc: CDI-Dev > >>>>> >>>>>> > > >>>>> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... > >>>>> >>>>>> > >>>>> >>>>>> Hi all, > >>>>> >>>>>> > >>>>> >>>>>> I would not like to add an XML "bloated" mechanism as part of > >>>>> >>>>>> CDI 2.0. > >>>>> >>>>>> Spontaneously I would propose a more CDI like things like: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> * Adding a @Configured annotation (basically a qualifier). > >>>>> >>>>>> This > >>>>> >>>>>> can be in addition to @Inject and would allow to inject > >>>>> >>>>>> "configured" values. > >>>>> >>>>>> * Since configuration can change we may think of a (CDI) > >>>>> >>>>>> event/reinject mechanism based on config changes. By default, > >>>>> >>>>>> this is > >>>>> >>>>>> switched off and we can discuss how it would be activated, > e.g. > >>>>> >>>>>> by an > >>>>> >>>>>> additional flag settable with the @Configured annotation, or > an > >>>>> >>>>>> additional > >>>>> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon > >>>>> >>>>>> framework), or both. > >>>>> >>>>>> * Hereby configured values theoretically behave similar as > >>>>> >>>>>> all > >>>>> >>>>>> other injection points. They also can be qualified (the aspect > >>>>> >>>>>> of scopes, I > >>>>> >>>>>> did not yet have time to think about). The only difference is, > >>>>> >>>>>> that they are > >>>>> >>>>>> satisified using the configuration "system". > >>>>> >>>>>> * The configuration "source" itself could in the extreme > >>>>> >>>>>> simplest > >>>>> >>>>>> way be a Provider>. The CDI spec should not > >>>>> >>>>>> care about > >>>>> >>>>>> how this map is provided (XML, DB, overrides, etc). This still > >>>>> >>>>>> can be > >>>>> >>>>>> standardized later. As long as the ConfigurationSource SPI is > >>>>> >>>>>> defined, > >>>>> >>>>>> companies still can hook in the logic and level of > configuration > >>>>> >>>>>> abstraction > >>>>> >>>>>> they need. > >>>>> >>>>>> * Of course, since not only Strings can be injected, we > need > >>>>> >>>>>> some > >>>>> >>>>>> conversion or adapter logic as basically outlined in my blog. > >>>>> >>>>>> Also here we > >>>>> >>>>>> can add a simple SPI and let the details to the RI. > >>>>> >>>>>> > >>>>> >>>>>> Summarizing a > >>>>> >>>>>> > >>>>> >>>>>> * @Configured annotation > >>>>> >>>>>> * some kind of change event > >>>>> >>>>>> * a ConfigurationSource extends > Provider> > >>>>> >>>>>> * a conversion mechanism from String to T. > >>>>> >>>>>> > >>>>> >>>>>> we get a full fledged configuration mechanism that leverages > >>>>> >>>>>> CDI. > >>>>> >>>>>> > >>>>> >>>>>> That would be my idea basically. WDYT? I will try to work that > >>>>> >>>>>> out in > >>>>> >>>>>> more details. Basically it should be implementable even with > the > >>>>> >>>>>> CDI > >>>>> >>>>>> mechanism already in place with CDI 1.1. > >>>>> >>>>>> > >>>>> >>>>>> Best, > >>>>> >>>>>> Anatole > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> antonio.goncalves at gmail.com>>: > >>>>> >>>>>> One wise man* once said "EJB was a hype specification, we > added > >>>>> >>>>>> too > >>>>> >>>>>> many things to it, it became bloated. The next hype > >>>>> >>>>>> specifications are > >>>>> >>>>>> JAX-RS and CDI, careful with them" > >>>>> >>>>>> > >>>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup > >>>>> >>>>>> being > >>>>> >>>>>> bloated. > >>>>> >>>>>> > >>>>> >>>>>> Antonio > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> *David Blevin > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand > >>>>> >>>>>> > > >>>>> >>>>>> wrote: > >>>>> >>>>>> Hi all, > >>>>> >>>>>> > >>>>> >>>>>> You may have followed the rise and fall of the Java Config JSR > >>>>> >>>>>> > >>>>> >>>>>> ( > http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html > ). > >>>>> >>>>>> Anatole in CC was leading this initiative and I proposed him > to > >>>>> >>>>>> join > >>>>> >>>>>> us and explore if some part of his late-JSR could be done in > >>>>> >>>>>> CDI. > >>>>> >>>>>> > >>>>> >>>>>> I?m mainly thinking of > https://issues.jboss.org/browse/CDI-123 > >>>>> >>>>>> or > >>>>> >>>>>> related solution. If we achieve to have a majority of specs to > >>>>> >>>>>> integrate > >>>>> >>>>>> with CDI, our configuration solution would therefore become a > >>>>> >>>>>> configuration > >>>>> >>>>>> system for all spec based on CDI 2.0. > >>>>> >>>>>> > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Antonio Goncalves > >>>>> >>>>>> Software architect, Java Champion and Pluralsight author > >>>>> >>>>>> > >>>>> >>>>>> Web site | > >>>>> >>>>>> Twitter | > >>>>> >>>>>> LinkedIn | > >>>>> >>>>>> > >>>>> >>>>>> Pluralsight< > http://pluralsight.com/training/Authors/Details/antonio-goncalves> > >>>>> >>>>>> | Paris JUG | Devoxx > >>>>> >>>>>> France > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Anatole Tresch > >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>>> Gl?rnischweg 10 > >>>>> >>>>>> CH - 8620 Wetzikon > >>>>> >>>>>> > >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>>> Twitter: @atsticks > >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>>> Google: atsticks > >>>>> >>>>>> Mobile +41-76 344 62 79 > >>>>> >>>>>> -------------- next part -------------- > >>>>> >>>>>> An HTML attachment was scrubbed... > >>>>> >>>>>> URL: > >>>>> >>>>>> > >>>>> >>>>>> > http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 > >>>>> >>>>>> *************************************** > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> -- > >>>>> >>>>>> Anatole Tresch > >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>>> Gl?rnischweg 10 > >>>>> >>>>>> CH - 8620 Wetzikon > >>>>> >>>>>> > >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>>> Twitter: @atsticks > >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>>> Google: atsticks > >>>>> >>>>>> Mobile +41-76 344 62 79 > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> 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. > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> -- > >>>>> >>>>> Anatole Tresch > >>>>> >>>>> Java Lead Engineer, JSR Spec Lead > >>>>> >>>>> Gl?rnischweg 10 > >>>>> >>>>> CH - 8620 Wetzikon > >>>>> >>>>> > >>>>> >>>>> Switzerland, Europe Zurich, GMT+1 > >>>>> >>>>> Twitter: @atsticks > >>>>> >>>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >>>>> Google: atsticks > >>>>> >>>>> Mobile +41-76 344 62 79 > >>>>> >>>> > >>>>> >>>> > >>>>> >>> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> -- > >>>>> >> Anatole Tresch > >>>>> >> Java Lead Engineer, JSR Spec Lead > >>>>> >> Gl?rnischweg 10 > >>>>> >> CH - 8620 Wetzikon > >>>>> >> > >>>>> >> Switzerland, Europe Zurich, GMT+1 > >>>>> >> Twitter: @atsticks > >>>>> >> Blogs: http://javaremarkables.blogspot.ch/ > >>>>> >> Google: atsticks > >>>>> >> Mobile +41-76 344 62 79 > >>>>> > > >>>>> > > >>>>> > > >>>>> > _______________________________________________ > >>>>> > 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. > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Anatole Tresch > >>>> Java Lead Engineer, JSR Spec Lead > >>>> Gl?rnischweg 10 > >>>> CH - 8620 Wetzikon > >>>> > >>>> Switzerland, Europe Zurich, GMT+1 > >>>> Twitter: @atsticks > >>>> Blogs: http://javaremarkables.blogspot.ch/ > >>>> Google: atsticks > >>>> Mobile +41-76 344 62 79 > >>> > >>> > >>> _______________________________________________ > >>> 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. > >> > >> > >> > >> > >> -- > >> Antonio Goncalves > >> Software architect, Java Champion and Pluralsight author > >> > >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > > _______________________________________________ > 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. > -- *Anatole Tresch* Java Lead Engineer, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/20a7e6d0/attachment-0001.html From werner.keil at gmail.com Mon Sep 8 17:21:41 2014 From: werner.keil at gmail.com (Werner Keil) Date: Mon, 8 Sep 2014 23:21:41 +0200 Subject: [cdi-dev] Java Config and CDI - A Minimal Outline In-Reply-To: References: Message-ID: CDI extension, like DeltaSpike ;-) Sounds reasonable, Werner On Mon, Sep 8, 2014 at 9:35 PM, Anatole Tresch wrote: > Therefore we should probably think of > > - ensure we have hooks in CDI 2, where we can put the config mechanism > into to configure (control?) CDI itself. > > All the rest can be done by just deploying and activating a CDI extension. > I will write a blog on that soon (it is already working here on my machine > with CDI 1.2 ;-) ). > > Then we should try getting a SE JSR up and running (let us discuss that > during J1 and at the next EC meeting) to define how we define, assemble and > manage config in general. CDI then is only one of multiple possible > consumers. > > -Anatole > > > 2014-09-08 17:20 GMT+02:00 Mark Struberg : > >> Antonio, the problem is that the config mechanism would need to be plain >> old java. In the best case even without classpath scanning. >> We need it during the boot time of the container (CDI and all other EE >> components boot time) so we cannot use CDI mechanics. >> >> If you look at DeltaSpike you will see that ConfigResolver just uses >> plain static methods. This is the only way we can use the config mechanism >> during boot time, e.g. to exclude classes in ProcessAnnotatedType, etc. >> >> The CDI part are only a few producers on top of it. We really need some >> common ground for configuration, but I don't think the CDI spec is the >> place where it should be handled... >> >> LieGrue, >> strub >> >> >> >> On Monday, 8 September 2014, 15:32, Antonio Goncalves < >> antonio.goncalves at gmail.com> wrote: >> >> >> >> It's just a matter of knowing what we want to do : >> >> * Add configuration into CDI 2.0 : it goes into the spec >> * Forget about configuration : it goes nowhere >> * Give configuration a chance for later : start the brainstorming, define >> an API, make sure it works with CDI 2.0... and leave the work in the >> appendix so the Java EE 9 expert group can read it and decide if they >> should take it or not. Appendixe is just a way of saying "we've deeply >> thought about it, this is the way we think it should be done, now the >> future EG decides" >> >> Antonio >> >> On Mon, Sep 8, 2014 at 11:51 AM, Romain Manni-Bucau < >> rmannibucau at gmail.com> wrote: >> >> @Antonio: -1 for an appendix, bean validation is the example it is >> broken. Idea is awesome, everybody liked it so it was added -> great. >> Here everybody already agrees it is good so no need of "staging" phase >> IMHO. BV appendix was not the API used so it broke apps using it. SO >> using proprietary stuff is the same, it basically mean an appendix >> spec for something not under discussion (regarding its need) is IMHO >> useless. >> >> >> Romain Manni-Bucau >> Twitter: @rmannibucau >> Blog: http://rmannibucau.wordpress.com/ >> LinkedIn: http://fr.linkedin.com/in/rmannibucau >> Github: https://github.com/rmannibucau >> >> >> 2014-09-08 10:29 GMT+02:00 Werner Keil : >> > Hi, >> > >> > If it's not really usable as API or annotation I don't see much value in >> > adding some "how to" or intent for the future into the Spec Document. >> > >> > If it was to become a part of CDI 2, there's nothing against optionality >> > like MEEP 8 or JSR 363 already practice on the SE/EE side either. >> > >> > Agorava/DeltaSpike demonstrate how true modularity work, similar to the >> JSRs >> > mentioned above, where you have multiple module JARs/bundles instead of >> a >> > big monolithic one. Some JSRs like Batch also declared separate >> "annotation" >> > modules, so that's what CDI 2 should also do if it was a feature Inside >> of >> > it. >> > Calling some features optional if they're not used by every >> implementation >> > allows them to chose. That was also the main value of keeping @Inject a >> > separate "module" under CDI. It was never included into a JDK but used >> > independently. >> > >> > The core of a Config module would ideally work in SE, but CDI 2 already >> > declared an aim to have some modules work under SE. >> > >> > Werner >> > >> > Am 08.09.2014 09:47 schrieb "Antonio Goncalves" >> > : >> > >> >> Hi all, >> >> >> >> I really have some concerns about adding configuration into CDI but I >> can >> >> see benefits too. And what about adding it... and not adding it at the >> same >> >> time ? In Bean Validation 1.0, the Expert Group decided not to include >> >> method-level validation in the spec (it was included in 1.1). But what >> they >> >> did is to add it as a proposal in the Appendix. >> >> >> >> If we feel some configuration should get in, why not have a proposal in >> >> the Appendix of CDI 2.0 ? It could then be implemented by Weld (and >> >> OpenWebBeans if they feel like it). And then, if it's successful and >> things >> >> get easier, get its own JSR for Java EE 9. >> >> >> >> WDYT ? >> >> >> >> Antonio >> >> >> >> On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau < >> rmannibucau at gmail.com> >> >> wrote: >> >>> >> >>> Hmm >> >>> >> >>> I see config jsr as a jse spec which would allow EE injections in >> config >> >>> components in EE containers (exactly like jbatch). >> >>> >> >>> This way it can be used without any container or with any container >> >>> easily. Only limit will be to not do something cdi/known containers >> will not >> >>> support I think. >> >>> >> >>> Not sure EE side is needed today, a lot can already be done without it >> >>> and it can be enhanced later adding some integration words. >> >>> >> >>> Le 8 sept. 2014 00:01, "Anatole Tresch" a ?crit >> : >> >>> >> >>>> Hi Romain >> >>>> >> >>>> just a few remarks inline... >> >>>> >> >>>> Summarizing >> >>>> 1) injection of values, reinjection, feedback on config changes can >> all >> >>>> be done with already existing features (producers, extensions). >> >>>> 2) configuring/bootstrapping CDI itself, e.g. configuration, is >> targeted >> >>>> with CDI 2.0 (see spec failing) >> >>>> >> >>>> So basically we could try to look if there is enough interest to >> >>>> standardize configuration in a more general way. For deployment >> aspects we >> >>>> need an EE JSR, for the rest, another SE standard may be an option as >> >>>> well... tbd... >> >>>> >> >>>> -Anatole >> >>>> >> >>>> >> >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau > >: >> >>>>> >> >>>>> well sorry to pop in so late but here are my 2cts >> >>>> >> >>>> easy ;) >> >>>> >> >>>>> >> >>>>> Config JSR is more about environment config IMHO and putting it in >> CDI >> >>>>> doesn't make sense since more or more spec works without any other >> >>>>> spec - CDI in our case. >> >>>> >> >>>> CDI even with some config mechanism added would still work >> "standalone". >> >>>> >> >>>> >> >>>>> >> >>>>> This mean CDI can't be the place but should >> >>>>> just be the bridge for config JSR. >> >>>> >> >>>> As I suggested as well. >> >>>> >> >>>> >> >>>>> >> >>>>> Plus CDI config will surely highly >> >>>>> be an application config first (beans.xml should be the place then) >> >>>> >> >>>> Yes, app config, but beware people of writing config into beans.xml. >> >>>> That is definitively in most cases not what you want. CDI should not >> define, >> >>>> where and how config is located and formatted. CDI should provide a >> SPI, >> >>>> where config providers can publish the configured values, so it can >> be >> >>>> injected wherever needed. E.g. some kind of producer, that can >> provide >> >>>> multiple objects to be injected and can benefit from some kind of >> callback >> >>>> mechanism would be sufficient... >> >>>> >> >>>>> >> >>>>> then environment config can be done at EE level (saying it has to >> >>>>> support placeholders or any pre deployment processing). >> >>>> >> >>>> Config is much more complex. There is no clear border what is >> >>>> environment config or environment dependent and what not. This >> depends on >> >>>> what kind of application you have deployed. As an example the email >> address, >> >>>> where you send error messages, can be different depenending on the >> >>>> stage/environment, but this is not EE related config entry. Also >> what an >> >>>> environment is, is not a thing that you can define completely. So I >> agree >> >>>> not to add this complexities to CDI, I would hide them between some >> kind of >> >>>> "config provider", as mentioned above. CDI does not need to know if >> the >> >>>> config provided is environment dependent or not, its just what is >> visible at >> >>>> a current runtime state... >> >>>> >> >>>>> >> >>>>> If you put something like ProjectStage in CDI it is great but then >> you >> >>>>> have it in JSF, CDI and finally surely all specs...same as >> >>>>> converters... >> >>>> >> >>>> That was originally the idea, when doing a EE config JSR, but without >> >>>> such standard. I agree, CDI is not the place to define them. >> >>>> >> >>>> >> >>>>> >> >>>>> Config should really be split in: >> >>>>> 1) spec dependent config -> spec.xml >> >>>>> 2) *common* config (a bit like javax.annotation) for environment and >> >>>>> external configuration -> Config JSR >> >>>> >> >>>> Not 100% sure, if a get the point here... >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau > >: >> >>>>> >> >>>>> well sorry to pop in so late but here are my 2cts >> >>>>> >> >>>>> Config JSR is more about environment config IMHO and putting it in >> CDI >> >>>>> doesn't make sense since more or more spec works without any other >> >>>>> spec - CDI in our case. This mean CDI can't be the place but should >> >>>>> just be the bridge for config JSR. Plus CDI config will surely >> highly >> >>>>> be an application config first (beans.xml should be the place then) >> >>>>> then environment config can be done at EE level (saying it has to >> >>>>> support placeholders or any pre deployment processing). >> >>>>> >> >>>>> If you put something like ProjectStage in CDI it is great but then >> you >> >>>>> have it in JSF, CDI and finally surely all specs...same as >> >>>>> converters... >> >>>>> >> >>>>> Config should really be split in: >> >>>>> 1) spec dependent config -> spec.xml >> >>>>> 2) *common* config (a bit like javax.annotation) for environment and >> >>>>> external configuration -> Config JSR >> >>>>> >> >>>>> wdyt? >> >>>>> >> >>>>> >> >>>>> >> >>>>> Romain Manni-Bucau >> >>>>> Twitter: @rmannibucau >> >>>>> Blog: http://rmannibucau.wordpress.com/ >> >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >> >>>>> Github: https://github.com/rmannibucau >> >>>>> >> >>>>> >> >>>>> 2014-09-07 23:39 GMT+02:00 Werner Keil : >> >>>>> > Sounds like an argument for a CDI module rather than a separate >> JSR >> >>>>> > then?;-) >> >>>>> > >> >>>>> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch < >> atsticks at gmail.com> >> >>>>> > wrote: >> >>>>> >> >> >>>>> >> I would not worry about CDI regarding licensing. Just the >> sentence >> >>>>> >> was >> >>>>> >> that Oracle does not want to have more ALv2 in addition to what >> is >> >>>>> >> already >> >>>>> >> there. So as long as we do things within CDI, no worries, I >> think. >> >>>>> >> For new >> >>>>> >> EE JSRs nevertheless this is a BIG issue and should be clarified >> by >> >>>>> >> the EC! >> >>>>> >> >> >>>>> >> >> >>>>> >> 2014-09-07 21:44 GMT+02:00 Werner Keil : >> >>>>> >>> >> >>>>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec >> under >> >>>>> >>> ALv2 >> >>>>> >>> as a dual-license, this was discussed by EC Members but both >> JCP EC >> >>>>> >>> and >> >>>>> >>> Oracle Legal/PMO seems fine with it, and CDI is already an >> >>>>> >>> essential >> >>>>> >>> building block to Java EE 6/7, hence used with Glassfish, too. I >> >>>>> >>> wasn't >> >>>>> >>> involved in these discussions, but given CDI is especially >> liberal >> >>>>> >>> and fully >> >>>>> >>> accepted by JCP formalities and license policies, I don't really >> >>>>> >>> see what >> >>>>> >>> the problem wss for Anatole's JSR attempt (though I know, both >> >>>>> >>> Oracle and >> >>>>> >>> other EC Members/companies don't always prefer this kind of >> >>>>> >>> licensing...;-) >> >>>>> >>> >> >>>>> >>> Werner >> >>>>> >>> >> >>>>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament >> >>>>> >>> >> >>>>> >>> wrote: >> >>>>> >>>> >> >>>>> >>>> Ok, this mail has me more concerned than anything. Can you >> >>>>> >>>> clarify this >> >>>>> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. >> >>>>> >>>> >> >>>>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch >> >>>>> >>>> >> >>>>> >>>> wrote: >> >>>>> >>>>> >> >>>>> >>>>> Hi All >> >>>>> >>>>> >> >>>>> >>>>> unfortunately things seem quite complicated: >> >>>>> >>>>> >> >>>>> >>>>> first of all, similarities with Deltaspike are basically not >> >>>>> >>>>> accidental. The concepts we developed in Credit Suisse are >> very >> >>>>> >>>>> similar to >> >>>>> >>>>> Deltaspike, though Deltaspike was not yet born at that time. >> >>>>> >>>>> Fortunately we >> >>>>> >>>>> ended up with a similar kind of solution. >> >>>>> >>>>> filtering still can be done. My idea is to define some kind of >> >>>>> >>>>> "configuration provider", which then is dynamically asked for >> >>>>> >>>>> configuration. >> >>>>> >>>>> How the provider is internally organized, is completely >> >>>>> >>>>> transparent to CDI. >> >>>>> >>>>> This enables to have multi-layered, complex config solutions >> work >> >>>>> >>>>> the same >> >>>>> >>>>> (from a view point of CDI) like simple programmatic test >> >>>>> >>>>> configurations >> >>>>> >>>>> during unit tests. The config provider still can support >> >>>>> >>>>> filtering and >> >>>>> >>>>> dynamic resolution as commonly used in configuration systems. >> >>>>> >>>>> Similarly the >> >>>>> >>>>> format is basically also not fixed. Of course, would a >> reference >> >>>>> >>>>> implementation provide a set of functionalities, but I would >> >>>>> >>>>> definitively >> >>>>> >>>>> not define the exact configuration mechanism as part of the >> CDI >> >>>>> >>>>> (or even a >> >>>>> >>>>> EE config JSR). Another reason, beside complexity and time, is >> >>>>> >>>>> the fact that >> >>>>> >>>>> different companies handle, store and manage configuration >> >>>>> >>>>> differently, so a >> >>>>> >>>>> mechanism must be flexible enough to accommodate these, >> without >> >>>>> >>>>> adoption >> >>>>> >>>>> rate will be low. Furthermore this flexibility also keeps >> doors >> >>>>> >>>>> open for use >> >>>>> >>>>> cases we do not know yet. >> >>>>> >>>>> Also we have to separate some basically two types of >> >>>>> >>>>> configuration >> >>>>> >>>>> aspects: >> >>>>> >>>>> >> >>>>> >>>>> application config basically is injected into deployed >> >>>>> >>>>> components, but >> >>>>> >>>>> basically only can affect deployment to the extend it can be >> >>>>> >>>>> managed and >> >>>>> >>>>> injected by CDI. The basic architecture and design, how >> >>>>> >>>>> application servers >> >>>>> >>>>> to load and deploy are basically not affected. This type of >> >>>>> >>>>> configuration >> >>>>> >>>>> (mechanism) I see also as a possible addition to CDI, if we >> >>>>> >>>>> really fail to >> >>>>> >>>>> do something in another JSR. With CDI going for a more modular >> >>>>> >>>>> design, even >> >>>>> >>>>> basic configuration of CDI can be possible, given we have some >> >>>>> >>>>> kind of API, >> >>>>> >>>>> we can access during CDI initialization. >> >>>>> >>>>> On the other side deployment configuration affects directly >> how >> >>>>> >>>>> the >> >>>>> >>>>> application server deploys the application. Configuration here >> >>>>> >>>>> would allow >> >>>>> >>>>> to define datasources, EJBs, transactional aspects, security, >> >>>>> >>>>> persistence, >> >>>>> >>>>> war and ear configurations etc. Basically everything you do >> as of >> >>>>> >>>>> today with >> >>>>> >>>>> some kind of XML file, or annotation. Hereby enabling more >> >>>>> >>>>> flexibility into >> >>>>> >>>>> the existing descriptors is relatively easy, but as mentioned >> by >> >>>>> >>>>> Mark, >> >>>>> >>>>> constraint. Adding more flexibility raises other subtle >> problems. >> >>>>> >>>>> Imagine a >> >>>>> >>>>> application module, e.g. a war, that defines everything it >> >>>>> >>>>> requires. There >> >>>>> >>>>> is no need to configure anything more on server side (with >> spring >> >>>>> >>>>> you can do >> >>>>> >>>>> this, with Java EE unfortunately not). But this has a severe >> >>>>> >>>>> consequence, it >> >>>>> >>>>> would make the application really portable in the sense, that >> it >> >>>>> >>>>> can be >> >>>>> >>>>> moved between different app servers (vendors) without any >> change >> >>>>> >>>>> (ideally). >> >>>>> >>>>> As a result commercial profits of some vendor companies may be >> >>>>> >>>>> affected. I >> >>>>> >>>>> think this is actually one of the key points, why things are >> >>>>> >>>>> getting so >> >>>>> >>>>> complicated in that area. >> >>>>> >>>>> >> >>>>> >>>>> Legal aspects also were discussed. One of them is a possible >> >>>>> >>>>> legal >> >>>>> >>>>> clash of ALv2 with GPL. This is the case already within >> >>>>> >>>>> Glassfish, but one >> >>>>> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal >> >>>>> >>>>> department. At >> >>>>> >>>>> the end we decided to use a BSD model. Even dual licensing >> >>>>> >>>>> BSD/ALv2 could >> >>>>> >>>>> theoretically be an option. If you would choose ALv2, Oracle >> will >> >>>>> >>>>> not >> >>>>> >>>>> include your RI into Glassfish, which is the RI for the EE >> >>>>> >>>>> Umbrella JSR, >> >>>>> >>>>> meaning your JSR will not be included into EE8. So what >> should we >> >>>>> >>>>> do? I >> >>>>> >>>>> don't have a good answer... >> >>>>> >>>>> >> >>>>> >>>>> So, I like to discuss configuration aspects here. >> Nevertheless if >> >>>>> >>>>> we >> >>>>> >>>>> decide to add config aspects, be aware that we might only >> >>>>> >>>>> (mainly) support >> >>>>> >>>>> application config, since everything else directly would >> impact >> >>>>> >>>>> other JSRs. >> >>>>> >>>>> And that is obviously quite similar to what Apache Deltaspike >> is >> >>>>> >>>>> all about >> >>>>> >>>>> ;-) >> >>>>> >>>>> >> >>>>> >>>>> Cheers, >> >>>>> >>>>> Anatole >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg : >> >>>>> >>>>>> >> >>>>> >>>>>> Yes, the config group also was (obviously) looking at >> >>>>> >>>>>> DeltaSpikes >> >>>>> >>>>>> config mechanism as well. >> >>>>> >>>>>> There were others who wanted to go more into the 'filtering' >> >>>>> >>>>>> approach >> >>>>> >>>>>> as done on WebLogic servers (though not sure who else does >> that >> >>>>> >>>>>> as well). >> >>>>> >>>>>> You know, having all the XML configs like WEB-INF/web.xml >> >>>>> >>>>>> containing >> >>>>> >>>>>> placeholders and the real values only get placed in there at >> >>>>> >>>>>> deployment >> >>>>> >>>>>> time. I personally find this approach a bit limited from a >> >>>>> >>>>>> technical >> >>>>> >>>>>> perspective and it already didn't work out for me when using >> >>>>> >>>>>> WebLogic (what >> >>>>> >>>>>> about changing a configured value after the deployment was >> done? >> >>>>> >>>>>> What about >> >>>>> >>>>>> security? Having passwords in web.xml, unit testing, ...). >> >>>>> >>>>>> There are of course also other approaches which all might >> have >> >>>>> >>>>>> strong >> >>>>> >>>>>> sides and would have needed to get discussed. >> >>>>> >>>>>> >> >>>>> >>>>>> But utterly the problem seems to have been legal reasons. We >> >>>>> >>>>>> even >> >>>>> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an >> ASF >> >>>>> >>>>>> project with >> >>>>> >>>>>> substantial support and participation from the JBoss, >> DeltaSpike >> >>>>> >>>>>> and TomEE >> >>>>> >>>>>> communities. >> >>>>> >>>>>> >> >>>>> >>>>>> Anyway, the time will come when we will resurrect this >> effort. >> >>>>> >>>>>> >> >>>>> >>>>>> LieGrue, >> >>>>> >>>>>> strub >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil >> >>>>> >>>>>> wrote: >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> Yep, it contains a simple but extendable notion of >> ProjectStage, >> >>>>> >>>>>> too;-) >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament >> >>>>> >>>>>> >> >>>>> >>>>>> wrote: >> >>>>> >>>>>> >> >>>>> >>>>>> Anatole, >> >>>>> >>>>>> >> >>>>> >>>>>> I'm wondering if some of your configuration description falls >> >>>>> >>>>>> under >> >>>>> >>>>>> what was put together in DeltaSpike? >> >>>>> >>>>>> >> >>>>> >>>>>> http://deltaspike.apache.org/configuration.html >> >>>>> >>>>>> >> >>>>> >>>>>> John >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch >> >>>>> >>>>>> >> >>>>> >>>>>> wrote: >> >>>>> >>>>>> >> >>>>> >>>>>> Staging is not a question of xml or not xml (the "format" of >> >>>>> >>>>>> config). >> >>>>> >>>>>> You can do staged config also using xml, or based on a >> database >> >>>>> >>>>>> or json >> >>>>> >>>>>> config service. Staging as well as, more generally speaking, >> >>>>> >>>>>> environment >> >>>>> >>>>>> dependent config is more like to select/filter the right >> config >> >>>>> >>>>>> that targets >> >>>>> >>>>>> the current (runtime) environment. This might include stages, >> >>>>> >>>>>> but also many >> >>>>> >>>>>> other aspects are feasible and common (server, tier, ear, >> war, >> >>>>> >>>>>> tenant ...). >> >>>>> >>>>>> Since these aspects are per se very complex, it might be >> >>>>> >>>>>> advisable to leave >> >>>>> >>>>>> them out of any spec (even a dedicated config JSR would >> probably >> >>>>> >>>>>> not be >> >>>>> >>>>>> capable of covering these within the relatively short EE >> >>>>> >>>>>> timeframe)... >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil < >> werner.keil at gmail.com>: >> >>>>> >>>>>> >> >>>>> >>>>>> Jens/all, >> >>>>> >>>>>> >> >>>>> >>>>>> A sort of "staging" already was possible using CDI earlier, >> see >> >>>>> >>>>>> examples like this: >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war >> >>>>> >>>>>> >> >>>>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond >> the >> >>>>> >>>>>> primitive, hard-coded JSF enum. >> >>>>> >>>>>> >> >>>>> >>>>>> If that works without XML, while still allowing flexible >> >>>>> >>>>>> configuration >> >>>>> >>>>>> for different stages or to add and "inject" additional >> stages >> >>>>> >>>>>> maybe even on >> >>>>> >>>>>> a tenant basis (for Cloud scenarios) I could see something >> like >> >>>>> >>>>>> that work >> >>>>> >>>>>> without XML. In the Multiconf project we managed to code >> >>>>> >>>>>> everything in >> >>>>> >>>>>> Python, and similar to Puppet or Chef you can configure and >> >>>>> >>>>>> deploy multiple >> >>>>> >>>>>> environments with it, Java EE, Spring or Play! several of >> them >> >>>>> >>>>>> are >> >>>>> >>>>>> configured this way and it requires no XML (where the >> container >> >>>>> >>>>>> needs such >> >>>>> >>>>>> files, the framework generates them;-) >> >>>>> >>>>>> >> >>>>> >>>>>> Werner >> >>>>> >>>>>> >> >>>>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, >> >>>>> >>>>>> >> >>>>> >>>>>> 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. Re: Tools : Google Drive vs Asciidoc and Github >> (Anatole >> >>>>> >>>>>> Tresch) >> >>>>> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >> >>>>> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() >> definition >> >>>>> >>>>>> (Anatole Tresch (JIRA)) >> >>>>> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) >> >>>>> >>>>>> >> >>>>> >>>>>> ------------------------------ >> >>>>> >>>>>> >> >>>>> >>>>>> Message: 4 >> >>>>> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >> >>>>> >>>>>> From: Jens Schumann >> >>>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... >> >>>>> >>>>>> To: Anatole Tresch , Antonio Goncalves >> >>>>> >>>>>> >> >>>>> >>>>>> Cc: cdi-dev >> >>>>> >>>>>> Message-ID: >> >>>>> >>>>>> Content-Type: text/plain; charset="windows-1252" >> >>>>> >>>>>> >> >>>>> >>>>>> I can confirm that this approach works very well. We are >> using a >> >>>>> >>>>>> similar approach a couple of years now, and I love the >> >>>>> >>>>>> simplicity that comes >> >>>>> >>>>>> with portable extensions and @Producer methods. See our >> public >> >>>>> >>>>>> version here >> >>>>> >>>>>> [1] (works since early CDI 1.0 days) . >> >>>>> >>>>>> >> >>>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier >> >>>>> >>>>>> @Property. >> >>>>> >>>>>> We support default values and type conversation for >> primitives >> >>>>> >>>>>> and >> >>>>> >>>>>> everything that has a string based constructor. The property >> >>>>> >>>>>> source can be >> >>>>> >>>>>> anything, from property files (default) to databases or xml >> >>>>> >>>>>> files. For >> >>>>> >>>>>> examples see tests here [2]. >> >>>>> >>>>>> >> >>>>> >>>>>> Nevertheless I am not sure if this should be part of an >> future >> >>>>> >>>>>> CDI >> >>>>> >>>>>> spec. My concerns include the bloat argument, of course. But >> the >> >>>>> >>>>>> main reason >> >>>>> >>>>>> relates to the fact that we have almost everything in the >> >>>>> >>>>>> current CDI spec >> >>>>> >>>>>> already. >> >>>>> >>>>>> >> >>>>> >>>>>> Right now I am quite happy with an custom portable extension >> >>>>> >>>>>> that does >> >>>>> >>>>>> everything for me. At the time we implemented the extension >> we >> >>>>> >>>>>> realised that >> >>>>> >>>>>> the "hard part" was writing an extension that links a >> qualified >> >>>>> >>>>>> "optional >> >>>>> >>>>>> injection point" with an @Producer method while supporting >> code >> >>>>> >>>>>> based >> >>>>> >>>>>> default values. Luckily I had Arne in my team who did that >> >>>>> >>>>>> within a few >> >>>>> >>>>>> minutes. >> >>>>> >>>>>> >> >>>>> >>>>>> Because of this experience I would propose that we simplify >> >>>>> >>>>>> extension >> >>>>> >>>>>> development such that "optional injection points" may be >> linked >> >>>>> >>>>>> to @Produces >> >>>>> >>>>>> values easily. Additionally we have to solve a few more >> >>>>> >>>>>> integration issues >> >>>>> >>>>>> (e.g. read-only DB access should be available during CDI >> >>>>> >>>>>> startup). >> >>>>> >>>>>> Everything else should be provided by portable extensions >> (e.g. >> >>>>> >>>>>> via >> >>>>> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. >> >>>>> >>>>>> >> >>>>> >>>>>> Jens >> >>>>> >>>>>> [1] >> >>>>> >>>>>> >> >>>>> >>>>>> >> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property >> >>>>> >>>>>> [2] >> >>>>> >>>>>> >> >>>>> >>>>>> >> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property >> >>>>> >>>>>> >> >>>>> >>>>>> Von: Anatole Tresch >> >>>>> >>>>>> > >> >>>>> >>>>>> Datum: Friday 5 September 2014 21:22 >> >>>>> >>>>>> An: Antonio Goncalves >> >>>>> >>>>>> >> >>>>> >>>>>> > antonio.goncalves at gmail.com>> >> >>>>> >>>>>> Cc: CDI-Dev >> >>>>> >>>>>> > >> >>>>> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... >> >>>>> >>>>>> >> >>>>> >>>>>> Hi all, >> >>>>> >>>>>> >> >>>>> >>>>>> I would not like to add an XML "bloated" mechanism as part of >> >>>>> >>>>>> CDI 2.0. >> >>>>> >>>>>> Spontaneously I would propose a more CDI like things like: >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> * Adding a @Configured annotation (basically a >> qualifier). >> >>>>> >>>>>> This >> >>>>> >>>>>> can be in addition to @Inject and would allow to inject >> >>>>> >>>>>> "configured" values. >> >>>>> >>>>>> * Since configuration can change we may think of a (CDI) >> >>>>> >>>>>> event/reinject mechanism based on config changes. By default, >> >>>>> >>>>>> this is >> >>>>> >>>>>> switched off and we can discuss how it would be activated, >> e.g. >> >>>>> >>>>>> by an >> >>>>> >>>>>> additional flag settable with the @Configured annotation, or >> an >> >>>>> >>>>>> additional >> >>>>> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon >> >>>>> >>>>>> framework), or both. >> >>>>> >>>>>> * Hereby configured values theoretically behave similar >> as >> >>>>> >>>>>> all >> >>>>> >>>>>> other injection points. They also can be qualified (the >> aspect >> >>>>> >>>>>> of scopes, I >> >>>>> >>>>>> did not yet have time to think about). The only difference >> is, >> >>>>> >>>>>> that they are >> >>>>> >>>>>> satisified using the configuration "system". >> >>>>> >>>>>> * The configuration "source" itself could in the extreme >> >>>>> >>>>>> simplest >> >>>>> >>>>>> way be a Provider>. The CDI spec should >> not >> >>>>> >>>>>> care about >> >>>>> >>>>>> how this map is provided (XML, DB, overrides, etc). This >> still >> >>>>> >>>>>> can be >> >>>>> >>>>>> standardized later. As long as the ConfigurationSource SPI is >> >>>>> >>>>>> defined, >> >>>>> >>>>>> companies still can hook in the logic and level of >> configuration >> >>>>> >>>>>> abstraction >> >>>>> >>>>>> they need. >> >>>>> >>>>>> * Of course, since not only Strings can be injected, we >> need >> >>>>> >>>>>> some >> >>>>> >>>>>> conversion or adapter logic as basically outlined in my blog. >> >>>>> >>>>>> Also here we >> >>>>> >>>>>> can add a simple SPI and let the details to the RI. >> >>>>> >>>>>> >> >>>>> >>>>>> Summarizing a >> >>>>> >>>>>> >> >>>>> >>>>>> * @Configured annotation >> >>>>> >>>>>> * some kind of change event >> >>>>> >>>>>> * a ConfigurationSource extends >> Provider> >> >>>>> >>>>>> * a conversion mechanism from String to T. >> >>>>> >>>>>> >> >>>>> >>>>>> we get a full fledged configuration mechanism that leverages >> >>>>> >>>>>> CDI. >> >>>>> >>>>>> >> >>>>> >>>>>> That would be my idea basically. WDYT? I will try to work >> that >> >>>>> >>>>>> out in >> >>>>> >>>>>> more details. Basically it should be implementable even with >> the >> >>>>> >>>>>> CDI >> >>>>> >>>>>> mechanism already in place with CDI 1.1. >> >>>>> >>>>>> >> >>>>> >>>>>> Best, >> >>>>> >>>>>> Anatole >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >> >>>>> >>>>>> >> >>>>> >>>>>> > antonio.goncalves at gmail.com>>: >> >>>>> >>>>>> One wise man* once said "EJB was a hype specification, we >> added >> >>>>> >>>>>> too >> >>>>> >>>>>> many things to it, it became bloated. The next hype >> >>>>> >>>>>> specifications are >> >>>>> >>>>>> JAX-RS and CDI, careful with them" >> >>>>> >>>>>> >> >>>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup >> >>>>> >>>>>> being >> >>>>> >>>>>> bloated. >> >>>>> >>>>>> >> >>>>> >>>>>> Antonio >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> *David Blevin >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand >> >>>>> >>>>>> > >> >>>>> >>>>>> wrote: >> >>>>> >>>>>> Hi all, >> >>>>> >>>>>> >> >>>>> >>>>>> You may have followed the rise and fall of the Java Config >> JSR >> >>>>> >>>>>> >> >>>>> >>>>>> ( >> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html >> ). >> >>>>> >>>>>> Anatole in CC was leading this initiative and I proposed him >> to >> >>>>> >>>>>> join >> >>>>> >>>>>> us and explore if some part of his late-JSR could be done in >> >>>>> >>>>>> CDI. >> >>>>> >>>>>> >> >>>>> >>>>>> I?m mainly thinking of >> https://issues.jboss.org/browse/CDI-123 >> >>>>> >>>>>> or >> >>>>> >>>>>> related solution. If we achieve to have a majority of specs >> to >> >>>>> >>>>>> integrate >> >>>>> >>>>>> with CDI, our configuration solution would therefore become a >> >>>>> >>>>>> configuration >> >>>>> >>>>>> system for all spec based on CDI 2.0. >> >>>>> >>>>>> >> >>>>> >>>>>> 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. >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> -- >> >>>>> >>>>>> Antonio Goncalves >> >>>>> >>>>>> Software architect, Java Champion and Pluralsight author >> >>>>> >>>>>> >> >>>>> >>>>>> Web site | >> >>>>> >>>>>> Twitter | >> >>>>> >>>>>> LinkedIn | >> >>>>> >>>>>> >> >>>>> >>>>>> Pluralsight< >> http://pluralsight.com/training/Authors/Details/antonio-goncalves> >> >>>>> >>>>>> | Paris JUG | Devoxx >> >>>>> >>>>>> France >> >>>>> >>>>>> >> >>>>> >>>>>> _______________________________________________ >> >>>>> >>>>>> 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. >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> -- >> >>>>> >>>>>> Anatole Tresch >> >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead >> >>>>> >>>>>> Gl?rnischweg 10 >> >>>>> >>>>>> CH - 8620 Wetzikon >> >>>>> >>>>>> >> >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >> >>>>> >>>>>> Twitter: @atsticks >> >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >> >>>>> >>>>>> Google: atsticks >> >>>>> >>>>>> Mobile +41-76 344 62 79 >> >>>>> >>>>>> -------------- next part -------------- >> >>>>> >>>>>> An HTML attachment was scrubbed... >> >>>>> >>>>>> URL: >> >>>>> >>>>>> >> >>>>> >>>>>> >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.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 46, Issue 20 >> >>>>> >>>>>> *************************************** >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> _______________________________________________ >> >>>>> >>>>>> 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. >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> -- >> >>>>> >>>>>> Anatole Tresch >> >>>>> >>>>>> Java Lead Engineer, JSR Spec Lead >> >>>>> >>>>>> Gl?rnischweg 10 >> >>>>> >>>>>> CH - 8620 Wetzikon >> >>>>> >>>>>> >> >>>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >> >>>>> >>>>>> Twitter: @atsticks >> >>>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >> >>>>> >>>>>> Google: atsticks >> >>>>> >>>>>> Mobile +41-76 344 62 79 >> >>>>> >>>>>> >> >>>>> >>>>>> _______________________________________________ >> >>>>> >>>>>> 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. >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> >> >>>>> >>>>>> _______________________________________________ >> >>>>> >>>>>> 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. >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> -- >> >>>>> >>>>> Anatole Tresch >> >>>>> >>>>> Java Lead Engineer, JSR Spec Lead >> >>>>> >>>>> Gl?rnischweg 10 >> >>>>> >>>>> CH - 8620 Wetzikon >> >>>>> >>>>> >> >>>>> >>>>> Switzerland, Europe Zurich, GMT+1 >> >>>>> >>>>> Twitter: @atsticks >> >>>>> >>>>> Blogs: http://javaremarkables.blogspot.ch/ >> >>>>> >>>>> Google: atsticks >> >>>>> >>>>> Mobile +41-76 344 62 79 >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> -- >> >>>>> >> Anatole Tresch >> >>>>> >> Java Lead Engineer, JSR Spec Lead >> >>>>> >> Gl?rnischweg 10 >> >>>>> >> CH - 8620 Wetzikon >> >>>>> >> >> >>>>> >> Switzerland, Europe Zurich, GMT+1 >> >>>>> >> Twitter: @atsticks >> >>>>> >> Blogs: http://javaremarkables.blogspot.ch/ >> >>>>> >> Google: atsticks >> >>>>> >> Mobile +41-76 344 62 79 >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > _______________________________________________ >> >>>>> > 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. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Anatole Tresch >> >>>> Java Lead Engineer, JSR Spec Lead >> >>>> Gl?rnischweg 10 >> >>>> CH - 8620 Wetzikon >> >>>> >> >>>> Switzerland, Europe Zurich, GMT+1 >> >>>> Twitter: @atsticks >> >>>> Blogs: http://javaremarkables.blogspot.ch/ >> >>>> Google: atsticks >> >>>> Mobile +41-76 344 62 79 >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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. >> >> >> >> >> >> >> >> >> >> -- >> >> Antonio Goncalves >> >> Software architect, Java Champion and Pluralsight author >> >> >> >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >> >> >> >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter >> | LinkedIn >> | Pluralsight >> | Paris >> JUG | Devoxx France >> >> _______________________________________________ >> 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. >> > > > > -- > *Anatole Tresch* > Java Lead Engineer, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > * > > *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/3cb81583/attachment-0001.html From werner.keil at gmail.com Mon Sep 8 17:24:58 2014 From: werner.keil at gmail.com (Werner Keil) Date: Mon, 8 Sep 2014 23:24:58 +0200 Subject: [cdi-dev] Enhancement proposition to JSR 330 In-Reply-To: <909BE9D6-14A3-4AC5-88DE-935EC563B8C3@sabot-durand.net> References: <909BE9D6-14A3-4AC5-88DE-935EC563B8C3@sabot-durand.net> Message-ID: Antoine, As seen, there could be Spring or other stakeholders who prefer either minimum JDK, so let's see if they actually propose it what they suggest (or in a draft upfront like some JSRs like MVC and others did) Werner On Mon, Sep 8, 2014 at 4:09 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Werner, > > Java EE 8 target is JDK 8 as we said before. But te goal of this document > is not to discuss with Bob and Juergen how they should use JDK 8 within > their spec, but to see if are willing to discuss our suggestion. When we?ll > find a general agreement it will be useful to go into such details. > > Antoine > > > Le 8 sept. 2014 ? 12:20, Werner Keil a ?crit : > > Antoine/all, > > Thanks for sharing. I also had a discussion (in his own Spring blog) with > J?rgen mainly about modularity, and the JDK minimum requirements for Spring > 4.x. He confirmed, the "core" components of Spring 4.1 still run under as > low as Java 6, while some modules that can be dynamically (Spring-DM aka > OSGi;-) added may directly refer to Java 8, in which case you must run SE 8 > or higher. > > So while for Java 6/7 or below version of @Inject.next this: > > public interface Provider extends Iterable { > /** > * Provides a fully-constructed and injected instance of {@code T}. > */ > T get(); > [...] > > looks fine, it seemed more than consequent, if you did > > public interface Provider extends Iterable, Supplier { > [...] > > in a Java 8+ case;-) > > Even without looking at Lambdas here in greater detail, it reused what > Java SE 8 introduced. > > Again, that is something you, Bob, J?rgen and maybe the EE 8 Spec Leads > should discuss, what the reasonable minimum requirements for @Inject.next > are, if it's SE 8 or a lower version, though those of course may always > stick with the previous ones... > > Werner > > On Mon, Sep 8, 2014 at 12:06 PM, 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. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >> (Romain Manni-Bucau (JIRA)) >> 2. Enhancement proposition to JSR 330 (Antoine Sabot-Durand) >> 3. Re: With the end of Java Config... (Werner Keil) >> >> >> ---------------------------------------------------------------------- >> >> Message: 2 >> Date: Mon, 8 Sep 2014 12:03:36 +0200 >> From: Antoine Sabot-Durand >> Subject: [cdi-dev] Enhancement proposition to JSR 330 >> To: cdi-dev >> Message-ID: >> Content-Type: text/plain; charset="us-ascii" >> >> Hi all, >> >> >> I received an answer from Bob Lee (off list). He likes te idea of us >> providing a proposal document. So I worked on it this WE. >> Here it is : >> https://docs.google.com/document/d/1KCzqodA8uzXED5DJrEUyl0x3dOUB5mBwL4KcV8xUY_w/edit?usp=sharing >> < >> https://docs.google.com/document/d/1KCzqodA8uzXED5DJrEUyl0x3dOUB5mBwL4KcV8xUY_w/edit?usp=sharing >> > >> >> Your comments and proposal are most welcome. I propose we discuss this >> point during our next meeting, and if we agree on the final content send it >> asap to have Bob and Juergen feeling about these suggestion. >> >> >> Antoine >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/607a6499/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 46, Issue 42 >> *************************************** >> > > _______________________________________________ > 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/20140908/65d022cc/attachment.html From antoine at sabot-durand.net Tue Sep 9 03:35:57 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 9 Sep 2014 09:35:57 +0200 Subject: [cdi-dev] Next meeting proposed agenda Message-ID: <05119CE0-8DC3-4B7C-ADE0-B5A4531C5518@sabot-durand.net> Hi all, So our next meeting will be tomorrow 16:00 UTC. I propose the following agenda : - Feedback on the AtInject++ proposal - Discussion on the pros and cons of creating a config workshop : following the passionate ML thread on the subject - Workshop discussion : volunteer to lead them and members If you have other points to see, please let me know. Antoine From antoine at sabot-durand.net Tue Sep 9 03:40:10 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 09 Sep 2014 07:40:10 +0000 Subject: [cdi-dev] Invitation: CDI weekly meeting @ Weekly from 18:00 to 19:00 on Wednesday (ASD Perso) Message-ID: <047d7b3a8ca0895e7805029d0bf4@google.com> You have been invited to the following event. Title: CDI weekly meeting When: Weekly from 18:00 to 19:00 on Wednesday Paris Where: IRC #cdi-dev channel on freenode Video call: https://plus.google.com/hangouts/_/sabot-durand.net/antoine Calendar: ASD Perso Who: * Antoine Sabot-Durand- organiser * cdi-dev at lists.jboss.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev at lists.jboss.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively, you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/e4091ce7/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1504 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/e4091ce7/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1551 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/e4091ce7/attachment-0003.bin From antoine at sabot-durand.net Tue Sep 9 03:44:21 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 09 Sep 2014 00:44:21 -0700 (PDT) Subject: [cdi-dev] =?utf-8?b?SW52aXRhdGlvbiDDoCBs4oCZw6l2w6luZW1lbnTCoDog?= =?utf-8?q?CDI_weekly_meeting?= Message-ID: <692C49BF-1A37-485D-B8BC-8BD4483E0908@sabot-durand.net> An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/0b9ddc97/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: iCal-Request.ics Type: text/calendar Size: 1513 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/0b9ddc97/attachment.bin From antoine at sabot-durand.net Tue Sep 9 03:45:02 2014 From: antoine at sabot-durand.net (antoine at sabot-durand.net) Date: Tue, 09 Sep 2014 07:45:02 +0000 Subject: [cdi-dev] Updated Invitation: CDI weekly meeting @ Weekly from 18:00 to 19:00 on Wednesday (ASD Perso) Message-ID: <001a11336bdaf038eb05029d1c76@google.com> This event has been changed. Title: CDI weekly meeting View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. (changed) When: Weekly from 18:00 to 19:00 on Wednesday Paris Where: IRC #cdi-dev channel on freenode Video call: https://plus.google.com/hangouts/_/sabot-durand.net/antoine Calendar: ASD Perso Who: * Antoine Sabot-Durand- organiser * cdi-dev at lists.jboss.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev at lists.jboss.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively, you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/6ec70606/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1772 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/6ec70606/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1823 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/6ec70606/attachment-0001.bin From antoine at sabot-durand.net Tue Sep 9 03:46:31 2014 From: antoine at sabot-durand.net (antoine at sabot-durand.net) Date: Tue, 09 Sep 2014 07:46:31 +0000 Subject: [cdi-dev] Updated Invitation: CDI weekly meeting @ Weekly from 18:00 to 19:00 on Wednesday (ASD Perso) Message-ID: <001a11c350a442d89305029d22ac@google.com> This event has been changed. Title: CDI weekly meeting View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. (changed) When: Weekly from 18:00 to 19:00 on Wednesday Paris Where: IRC #cdi-dev channel on freenode Video call: https://plus.google.com/hangouts/_/sabot-durand.net/antoine Calendar: ASD Perso Who: * Antoine Sabot-Durand- organiser * cdi-dev at lists.jboss.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev at lists.jboss.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively, you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/d6feeb7f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2042 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/d6feeb7f/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2096 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/d6feeb7f/attachment-0003.bin From antoine at sabot-durand.net Tue Sep 9 03:46:31 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 09 Sep 2014 00:46:31 -0700 (PDT) Subject: [cdi-dev] =?utf-8?b?QWN0dWFsaXNhdGlvbiBkZSBs4oCZw6l2w6luZW1lbnQ=?= =?utf-8?q?=C2=A0=3A_CDI_weekly_meeting?= Message-ID: <7A90F008-4227-4DA8-9028-4E501EDE2D70@sabot-durand.net> An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/a732e0b9/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: iCal-Request.ics Type: text/calendar Size: 1785 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/a732e0b9/attachment.bin From antoine at sabot-durand.net Tue Sep 9 03:47:29 2014 From: antoine at sabot-durand.net (antoine at sabot-durand.net) Date: Tue, 09 Sep 2014 07:47:29 +0000 Subject: [cdi-dev] Updated Invitation: CDI weekly meeting @ Weekly from 18:00 to 19:00 on Wednesday (ASD Perso) Message-ID: <001a11c3cc94b91e7505029d259d@google.com> This event has been changed. Title: CDI weekly meeting View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. When: Weekly from 18:00 to 19:00 on Wednesday Paris Where: IRC #cdi-dev channel on freenode Calendar: ASD Perso Who: * Antoine Sabot-Durand- organiser * cdi-dev at lists.jboss.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev at lists.jboss.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively, you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/2dd34b23/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2042 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/2dd34b23/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2096 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/2dd34b23/attachment-0001.bin From antoine at sabot-durand.net Tue Sep 9 03:48:15 2014 From: antoine at sabot-durand.net (antoine at sabot-durand.net) Date: Tue, 09 Sep 2014 07:48:15 +0000 Subject: [cdi-dev] Updated Invitation: CDI weekly meeting @ Weekly from 18:00 to 19:00 on Wednesday (ASD Perso) Message-ID: <089e01419e1c6eb36d05029d2840@google.com> This event has been changed. Title: CDI weekly meeting View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. (changed) When: Weekly from 18:00 to 19:00 on Wednesday Paris Where: IRC #cdi-dev channel on freenode Calendar: ASD Perso Who: * Antoine Sabot-Durand- organiser * cdi-dev at lists.jboss.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev at lists.jboss.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively, you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/80273235/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2314 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/80273235/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2372 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/80273235/attachment-0003.bin From antoine at sabot-durand.net Tue Sep 9 03:48:15 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 09 Sep 2014 00:48:15 -0700 (PDT) Subject: [cdi-dev] =?utf-8?b?QWN0dWFsaXNhdGlvbiBkZSBs4oCZw6l2w6luZW1lbnQ=?= =?utf-8?q?=C2=A0=3A_CDI_weekly_meeting?= Message-ID: An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/7c135dad/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: iCal-Request.ics Type: text/calendar Size: 2061 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/7c135dad/attachment.bin From issues at jboss.org Tue Sep 9 04:38:00 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 9 Sep 2014 04:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000169#comment-13000169 ] Antoine Sabot-Durand commented on CDI-456: ------------------------------------------ We all know there are issues with the Java EE module architecture. This has to be fix at Java EE level and CDI spec will have to follow not the other way around. Now, regarding this ticket I think Jozef explained more than once why {{Bean#getBeanClass()}} should behave this way. Yet I understand the need to get the exact type of a given bean instances. So IMO we should split this ticket in 2 : # Clarify the javadoc and spec description of {{Bean#getBeanClass()}} to avoid confusion # Add a new method to {{Bean}} returning the exact type of the bean instances. something like {{Bean#getInstanceClass()}} > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 9 04:44:01 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 9 Sep 2014 04:44:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000172#comment-13000172 ] Romain Manni-Bucau commented on CDI-456: ---------------------------------------- [~antoinesabot-durand] globally agree, I think producer (method/field) should also get a specific issue to make explicit that's a container thing (or allow providing new API to user to create some). This can make sense actually to allow to create programmatically producers > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From atsticks at gmail.com Tue Sep 9 09:49:44 2014 From: atsticks at gmail.com (Anatole Tresch) Date: Tue, 9 Sep 2014 15:49:44 +0200 Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: +1 2014-09-09 10:38 GMT+02:00 Antoine Sabot-Durand (JIRA) : > > [ > https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000169#comment-13000169 > ] > > Antoine Sabot-Durand commented on CDI-456: > ------------------------------------------ > > We all know there are issues with the Java EE module architecture. This > has to be fix at Java EE level and CDI spec will have to follow not the > other way around. > Now, regarding this ticket I think Jozef explained more than once why > {{Bean#getBeanClass()}} should behave this way. Yet I understand the need > to get the exact type of a given bean instances. So IMO we should split > this ticket in 2 : > > # Clarify the javadoc and spec description of {{Bean#getBeanClass()}} to > avoid confusion > # Add a new method to {{Bean}} returning the exact type of the bean > instances. something like {{Bean#getInstanceClass()}} > > > > > fix Bean#getBeanClass() definition > > ---------------------------------- > > > > Key: CDI-456 > > URL: https://issues.jboss.org/browse/CDI-456 > > Project: CDI Specification Issues > > Issue Type: Bug > > Components: Beans > > Reporter: Mark Struberg > > > > currently Bean#getBeanClass() is defined to return the class of the bean > it produces but has one important exception: in case of a producer method > or field it must return the class of the owner bean of this method or field. > > Imo this only causes troubles and doesn't add any benefit. > > * At the time when 'using' the Bean (create and destroy) we always ONLY > need the type which is to be created. > > * At the time we create interceptors we ONLY need the type which is to > be created; > > * At the time we create the normalscoping proxies we ONLY need the type > which is to be created; > > In fact the only time we need the ownerBean is when scanning the methods > and fields in it. And for creating we really need the owner-Bean and not > it's bean-class! > > In OWB we worked around this by having our own method getReturnType() > which consistently returns the type which gets created. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.1#6329) > _______________________________________________ > 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. > -- *Anatole Tresch* Java Lead Engineer, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140909/47de2b8b/attachment.html From issues at jboss.org Tue Sep 9 09:52:00 2014 From: issues at jboss.org (Anatole Tresch (JIRA)) Date: Tue, 9 Sep 2014 09:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000360#comment-13000360 ] Anatole Tresch commented on CDI-456: ------------------------------------ +1 -- *Anatole Tresch* Java Lead Engineer, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79* > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 06:23:19 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Thu, 11 Sep 2014 06:23:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-460) Support repeatable qualifiers In-Reply-To: References: Message-ID: Antonin Stefanutti created CDI-460: -------------------------------------- Summary: Support repeatable qualifiers Key: CDI-460 URL: https://issues.jboss.org/browse/CDI-460 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Affects Versions: 2.0 (discussion) Reporter: Antonin Stefanutti In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 06:23:20 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Thu, 11 Sep 2014 06:23:20 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-460) Support repeating qualifiers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated CDI-460: ----------------------------------- Summary: Support repeating qualifiers (was: Support repeatable qualifiers) > Support repeating qualifiers > ---------------------------- > > Key: CDI-460 > URL: https://issues.jboss.org/browse/CDI-460 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 2.0 (discussion) > Reporter: Antonin Stefanutti > > In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: > {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, > {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, > {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. > Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. > Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. > Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. > That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 06:34:19 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Thu, 11 Sep 2014 06:34:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-460) Support repeating qualifiers in CDI SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated CDI-460: ----------------------------------- Summary: Support repeating qualifiers in CDI SPI (was: Support repeating qualifiers) > Support repeating qualifiers in CDI SPI > --------------------------------------- > > Key: CDI-460 > URL: https://issues.jboss.org/browse/CDI-460 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 2.0 (discussion) > Reporter: Antonin Stefanutti > > In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: > {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, > {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, > {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. > Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. > Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. > Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. > That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 06:38:19 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Thu, 11 Sep 2014 06:38:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-460) Support repeating qualifiers in CDI SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated CDI-460: ----------------------------------- Description: In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. While that request is technically independent from Java 8, it is correlated to the support of repeating qualifiers in the typesafe resolution mechanism that is likely to be treated as part of the Java 8 stream of the CDI 2.0 specification. was: In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. > Support repeating qualifiers in CDI SPI > --------------------------------------- > > Key: CDI-460 > URL: https://issues.jboss.org/browse/CDI-460 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 2.0 (discussion) > Reporter: Antonin Stefanutti > > In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: > {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, > {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, > {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. > Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. > Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. > Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. > That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. > While that request is technically independent from Java 8, it is correlated to the support of repeating qualifiers in the typesafe resolution mechanism that is likely to be treated as part of the Java 8 stream of the CDI 2.0 specification. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antoine at sabot-durand.net Thu Sep 11 11:31:38 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 11 Sep 2014 17:31:38 +0200 Subject: [cdi-dev] revised version of AtInject next proposal Message-ID: <23DFD98B-F0D1-4202-A8FB-FEA8D21DC9C7@sabot-durand.net> Hi all, Following yesterday meeting decisions regarding AtInject proposals, I made some modification my doc to include the move of java.enterprise.util package. Result is here : https://docs.google.com/document/d/1KCzqodA8uzXED5DJrEUyl0x3dOUB5mBwL4KcV8xUY_w/edit?usp=sharing I propose to send the doc to Bob and Jurgen next monday. Until then, correct and new proposal are welcome. Antoine From antonio.goncalves at gmail.com Thu Sep 11 15:26:04 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Thu, 11 Sep 2014 21:26:04 +0200 Subject: [cdi-dev] revised version of AtInject next proposal In-Reply-To: <23DFD98B-F0D1-4202-A8FB-FEA8D21DC9C7@sabot-durand.net> References: <23DFD98B-F0D1-4202-A8FB-FEA8D21DC9C7@sabot-durand.net> Message-ID: We can't edit the document, I had to send a request to share it. Is that the way to do it ? Antonio On Thu, Sep 11, 2014 at 5:31 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > > Following yesterday meeting decisions regarding AtInject proposals, I made > some modification my doc to include the move of java.enterprise.util > package. > Result is here : > https://docs.google.com/document/d/1KCzqodA8uzXED5DJrEUyl0x3dOUB5mBwL4KcV8xUY_w/edit?usp=sharing > > I propose to send the doc to Bob and Jurgen next monday. Until then, > correct and new proposal are welcome. > > 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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140911/8cd07c67/attachment.html From antoine at sabot-durand.net Fri Sep 12 03:19:26 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 12 Sep 2014 09:19:26 +0200 Subject: [cdi-dev] Config workshop Message-ID: <46EABA83-ED93-495B-BC71-C36ED4813622@sabot-durand.net> Hi all, I just created the working doc for the config workshop. Anatole leads the initiative. If you want to be part of the team just ask. The (empty) doc is here : https://docs.google.com/document/d/1378aTRNgCMXRYP9LBYRuGdan0mmQ3rPjjIYLWv2AB9I/edit?usp=sharing regards, Antoine From issues at jboss.org Fri Sep 12 03:44:19 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Fri, 12 Sep 2014 03:44:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-104) Support automatic dependency injection for non-managed objects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001707#comment-13001707 ] Antonin Stefanutti commented on CDI-104: ---------------------------------------- >From my understanding, this need has been addressed with [{{UnmanagedInstance}}|http://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/spi/Unmanaged.UnmanagedInstance.html] as documented in [Obtaining non-contextual instance|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_obtain_unmanaged_instance] in CDI 1.1. Isn't it? > Support automatic dependency injection for non-managed objects > -------------------------------------------------------------- > > Key: CDI-104 > URL: https://issues.jboss.org/browse/CDI-104 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Dan Allen > Fix For: TBD > > > Allow objects created using the "new" keyword (or created by some other means) to be injected automatically. > Conceptually it would look something like this: > @AutoInject > public class AccountService { > private final Account account; > @Inject > private PaymentProcessor paymentProcessor; > AccountService(Account account) { > this.account = account; > } > public void doPayment(double amount) { > paymentProcessor.processPayment(account, amount); > } > } > We could then create the object using new and the fields will still be injected: > AccountService a = new AccountService(account); > a.doPayment(10); > The inverse design would also be an option. An instance of Account could be retrieved from JPA and the AccountService would be injected into it during construction. > To implement this feature may require a javaagent, which will modify the bytecode of @AutoInject annotated classes as they are loaded, so that the constructor bytecode looks up the values to inject and sets the injected field values appropriately. (There are other options suggested in the linked thread). > The primary use case for this feature is to support rich domain models, though the usefulness of this feature extends beyond this case, so I don't think the feature should be dismissed if you don't agree with the rich domain models design. > The feature also brings the "new" keyword back into the picture of modern programming. You can still create objects in the classic way, but benefit from modern programming model patterns (specifically CDI). > Spring has a similar feature in it's AOP package: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/aop.html#aop-atconfigurable -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 03:50:19 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Fri, 12 Sep 2014 03:50:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-460) Support repeating qualifiers in CDI SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated CDI-460: ----------------------------------- Issue Type: Clarification (was: Feature Request) > Support repeating qualifiers in CDI SPI > --------------------------------------- > > Key: CDI-460 > URL: https://issues.jboss.org/browse/CDI-460 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 2.0 (discussion) > Reporter: Antonin Stefanutti > > In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: > {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, > {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, > {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. > Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. > Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. > Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. > That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. > While that request is technically independent from Java 8, it is correlated to the support of repeating qualifiers in the typesafe resolution mechanism that is likely to be treated as part of the Java 8 stream of the CDI 2.0 specification. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antonio.goncalves at gmail.com Fri Sep 12 04:02:48 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Fri, 12 Sep 2014 10:02:48 +0200 Subject: [cdi-dev] Config workshop In-Reply-To: <46EABA83-ED93-495B-BC71-C36ED4813622@sabot-durand.net> References: <46EABA83-ED93-495B-BC71-C36ED4813622@sabot-durand.net> Message-ID: Hi, Again, I'm on read-only mode. Can't contribute. Antonio On Fri, Sep 12, 2014 at 9:19 AM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > I just created the working doc for the config workshop. Anatole leads the > initiative. If you want to be part of the team just ask. > > The (empty) doc is here : > https://docs.google.com/document/d/1378aTRNgCMXRYP9LBYRuGdan0mmQ3rPjjIYLWv2AB9I/edit?usp=sharing > > 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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140912/f0be902a/attachment.html From antoine at sabot-durand.net Fri Sep 12 04:31:53 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 12 Sep 2014 10:31:53 +0200 Subject: [cdi-dev] Config workshop In-Reply-To: References: <46EABA83-ED93-495B-BC71-C36ED4813622@sabot-durand.net> Message-ID: Hi Antonio, As stated in the ?contribution? section of these docs, I?d rather avoid having anonymous contribution and Google drive does? provide a way to support a sharing mode open to all signed person. That?s why people should ask to be added as contributor. I think we should let the workshop leader decide wether people can write directly to the doc or add content in suggestion mode (a better way to easily know who suggested what). I add you in suggestion mode and let Anatole lead the way the work is done here. Antoine > Le 12 sept. 2014 ? 10:02, Antonio Goncalves a ?crit : > > Hi, > > Again, I'm on read-only mode. Can't contribute. > > Antonio > > On Fri, Sep 12, 2014 at 9:19 AM, Antoine Sabot-Durand > wrote: > Hi all, > > I just created the working doc for the config workshop. Anatole leads the initiative. If you want to be part of the team just ask. > > The (empty) doc is here : https://docs.google.com/document/d/1378aTRNgCMXRYP9LBYRuGdan0mmQ3rPjjIYLWv2AB9I/edit?usp=sharing > > 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. > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140912/75953d34/attachment.html From issues at jboss.org Fri Sep 12 05:25:19 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 05:25:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-461) Configuration Workshop for CDI 2.0 In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-461: ---------------------------------------- Summary: Configuration Workshop for CDI 2.0 Key: CDI-461 URL: https://issues.jboss.org/browse/CDI-461 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Antoine Sabot-Durand This umbrella tickets gathers all tickets and work document about studying the possible introduction of configuration feature in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 05:25:19 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 05:25:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-461) Configuration Workshop for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-461: ------------------------------------- Fix Version/s: 2.0 (discussion) > Configuration Workshop for CDI 2.0 > ---------------------------------- > > Key: CDI-461 > URL: https://issues.jboss.org/browse/CDI-461 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This umbrella tickets gathers all tickets and work document about studying the possible introduction of configuration feature in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 05:27:19 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 05:27:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-461) Configuration Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-461: ------------------------------------- Summary: Configuration Epic for CDI 2.0 (was: Configuration Workshop for CDI 2.0) > Configuration Epic for CDI 2.0 > ------------------------------ > > Key: CDI-461 > URL: https://issues.jboss.org/browse/CDI-461 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This umbrella tickets gathers all tickets and work document about studying the possible introduction of configuration feature in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antonio.goncalves at gmail.com Fri Sep 12 05:27:24 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Fri, 12 Sep 2014 11:27:24 +0200 Subject: [cdi-dev] Config workshop In-Reply-To: References: <46EABA83-ED93-495B-BC71-C36ED4813622@sabot-durand.net> Message-ID: Makes sense. But I was more thinking of the AtInject document that you sent yesterday. I wouldn't mind contributing (as I have a few comments) but I'm not allowed. On Fri, Sep 12, 2014 at 10:31 AM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi Antonio, > > As stated in the ?contribution? section of these docs, I?d rather avoid > having anonymous contribution and Google drive does? provide a way to > support a sharing mode open to all signed person. That?s why people should > ask to be added as contributor. > I think we should let the workshop leader decide wether people can write > directly to the doc or add content in suggestion mode (a better way to > easily know who suggested what). I add you in suggestion mode and let > Anatole lead the way the work is done here. > > Antoine > > > Le 12 sept. 2014 ? 10:02, Antonio Goncalves > a ?crit : > > Hi, > > Again, I'm on read-only mode. Can't contribute. > > Antonio > > On Fri, Sep 12, 2014 at 9:19 AM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi all, >> >> I just created the working doc for the config workshop. Anatole leads the >> initiative. If you want to be part of the team just ask. >> >> The (empty) doc is here : >> https://docs.google.com/document/d/1378aTRNgCMXRYP9LBYRuGdan0mmQ3rPjjIYLWv2AB9I/edit?usp=sharing >> >> 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. >> > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > > > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140912/7c1a926f/attachment-0001.html From issues at jboss.org Fri Sep 12 06:15:21 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 06:15:21 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-461) Configuration Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-461: ------------------------------------- Description: This Epic ticket gathers all tickets and work document about studying the possible introduction of configuration feature in CDI 2.0. Draft document is here : https://docs.google.com/document/d/1378aTRNgCMXRYP9LBYRuGdan0mmQ3rPjjIYLWv2AB9I/edit?usp=sharing was:This umbrella tickets gathers all tickets and work document about studying the possible introduction of configuration feature in CDI 2.0. > Configuration Epic for CDI 2.0 > ------------------------------ > > Key: CDI-461 > URL: https://issues.jboss.org/browse/CDI-461 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all tickets and work document about studying the possible introduction of configuration feature in CDI 2.0. > Draft document is here : https://docs.google.com/document/d/1378aTRNgCMXRYP9LBYRuGdan0mmQ3rPjjIYLWv2AB9I/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 06:18:19 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 06:18:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-462) Parts Epic for CDI 2.0 In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-462: ---------------------------------------- Summary: Parts Epic for CDI 2.0 Key: CDI-462 URL: https://issues.jboss.org/browse/CDI-462 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Antoine Sabot-Durand Fix For: 2.0 (discussion) this Epic ticket gathers all tickets and work documents about the introudction of parts (modularity) in CDI 2.0 Draft document is here : https://docs.google.com/document/d/1AEBjQl00CZ9ERfgXSHq9cdxrngwsERjUCEmcdzgMSZ4/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 06:22:19 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 06:22:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-463) Events Epic for CDI 2.0 In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-463: ---------------------------------------- Summary: Events Epic for CDI 2.0 Key: CDI-463 URL: https://issues.jboss.org/browse/CDI-463 Project: CDI Specification Issues Issue Type: Feature Request Components: Events Reporter: Antoine Sabot-Durand Fix For: 2.0 (discussion) This Epic ticket gathers all work and documents about possible events enhancement in CDI 2.0 Draft document is here : https://docs.google.com/document/d/1lFtgLm6hY-uECdA1r0Sfimq6vkVYThoUZsevPUaSP0E/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 06:24:19 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 06:24:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-464) Java SE Epic for CDI 2.0 In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-464: ---------------------------------------- Summary: Java SE Epic for CDI 2.0 Key: CDI-464 URL: https://issues.jboss.org/browse/CDI-464 Project: CDI Specification Issues Issue Type: Feature Request Components: Java SE Integration Reporter: Antoine Sabot-Durand Fix For: 2.0 (discussion) This Epic ticket gathers all work and documents about Java SE bootstrap in CDI 2.0 Draft document is here : https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From pmuir at redhat.com Fri Sep 12 07:00:45 2014 From: pmuir at redhat.com (Pete Muir) Date: Fri, 12 Sep 2014 12:00:45 +0100 Subject: [cdi-dev] Config workshop In-Reply-To: References: <46EABA83-ED93-495B-BC71-C36ED4813622@sabot-durand.net> Message-ID: Antonio, Hit the Share button in the top right, and request access. Pete On 12 Sep 2014, at 10:27, Antonio Goncalves wrote: > Makes sense. But I was more thinking of the AtInject document that you sent yesterday. I wouldn't mind contributing (as I have a few comments) but I'm not allowed. > > On Fri, Sep 12, 2014 at 10:31 AM, Antoine Sabot-Durand wrote: > Hi Antonio, > > As stated in the ?contribution? section of these docs, I?d rather avoid having anonymous contribution and Google drive does? provide a way to support a sharing mode open to all signed person. That?s why people should ask to be added as contributor. > I think we should let the workshop leader decide wether people can write directly to the doc or add content in suggestion mode (a better way to easily know who suggested what). I add you in suggestion mode and let Anatole lead the way the work is done here. > > Antoine > > >> Le 12 sept. 2014 ? 10:02, Antonio Goncalves a ?crit : >> >> Hi, >> >> Again, I'm on read-only mode. Can't contribute. >> >> Antonio >> >> On Fri, Sep 12, 2014 at 9:19 AM, Antoine Sabot-Durand wrote: >> Hi all, >> >> I just created the working doc for the config workshop. Anatole leads the initiative. If you want to be part of the team just ask. >> >> The (empty) doc is here : https://docs.google.com/document/d/1378aTRNgCMXRYP9LBYRuGdan0mmQ3rPjjIYLWv2AB9I/edit?usp=sharing >> >> 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. >> >> >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > _______________________________________________ > 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/20140912/bcd24225/attachment.html From issues at jboss.org Fri Sep 12 08:55:24 2014 From: issues at jboss.org (Thomas Andraschko (JIRA)) Date: Fri, 12 Sep 2014 08:55:24 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-224) Support Decoration of no interface beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001842#comment-13001842 ] Thomas Andraschko commented on CDI-224: --------------------------------------- "outcry" :D We have a big product with many subproducts and customizations for customers. In our core libs, we have many default view controllers beans and JSF cc's/includes.. For some subproducts, we @Specialize the view controllers or even create seperate includes. e.g. core -> ViewAController subprojectA -> SpecializedViewAController Thats work fine with @Specialized/@Alternative. We also have shared libs for each customer. There we would like to decorate e.g. ViewAController. As our controller are currently classes, it would be perfect if it would be possible to apply decorators also on classes. Currently we have to introduce interfaces for our view controllers, which is actually only a workaround for this feature request because we don't gain any other benefit from it. > Support Decoration of no interface beans > ---------------------------------------- > > Key: CDI-224 > URL: https://issues.jboss.org/browse/CDI-224 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Assignee: Pete Muir > > According to CDI 1.0 Spec: > "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean." > "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator." > Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes. > I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place. > {code} > import javax.decorator.Decorator; > import javax.decorator.Delegate; > import javax.enterprise.inject.Any; > import javax.inject.Inject; > import junit.framework.Assert; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.ShrinkWrap; > import org.jboss.shrinkwrap.api.spec.WebArchive; > import org.jboss.shrinkwrap.impl.BeansXml; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class DecoratesClassTestCase { > @Deployment > public static WebArchive create() { > return ShrinkWrap.create(WebArchive.class) > .addAsWebInfResource( > new BeansXml().decorators(BusinessDecorator.class), "beans.xml"); > } > > @Test > public void shouldBeAbleToDecorate(BusinessObject business) throws Exception { > Assert.assertEquals("Decorated Test", business.send("Test")); > } > > @Decorator > public static abstract class BusinessDecorator extends BusinessObject { > @Inject @Delegate @Any > private BusinessObject delegate; > > public String send(String msg) { > return "Decorated " + delegate.send(msg); > } > } > > public static class BusinessObject { > > public String send(String msg) { > return msg; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From john.d.ament at gmail.com Fri Sep 12 09:26:01 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Fri, 12 Sep 2014 09:26:01 -0400 Subject: [cdi-dev] CDI 1.1 -> Release in JIRA? Message-ID: All, Should the 1.1 releases be marked as released in JIRA? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140912/03df5915/attachment-0001.html From issues at jboss.org Fri Sep 12 09:42:20 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 09:42:20 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-465) SPI Epic for CDI 2.0 In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-465: ---------------------------------------- Summary: SPI Epic for CDI 2.0 Key: CDI-465 URL: https://issues.jboss.org/browse/CDI-465 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Antoine Sabot-Durand Fix For: 2.0 (discussion) This Epic ticket gathers all work and documents about possible SPI enhancement in CDI 2.0 Draft document is here : https://docs.google.com/document/d/1aK3aIQG-W9D72Ti9fj0xLFNmqxQtYyy_vjc6QgN3Z2Y/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 09:44:19 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 09:44:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-466) Contexts Epic for CDI 2.0 In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-466: ---------------------------------------- Summary: Contexts Epic for CDI 2.0 Key: CDI-466 URL: https://issues.jboss.org/browse/CDI-466 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Antoine Sabot-Durand Fix For: 2.0 (discussion) This Epic ticket gathers all work and documents about possible contexts enhancement in CDI 2.0 Draft document is here : https://docs.google.com/document/d/1tIFNoe9sdyvXT1wTjIeT7ARDaoRZR0IWzcfvKrmdIX4/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 09:46:19 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 09:46:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-467) Java 8 Epic for CDI 2.0 In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-467: ---------------------------------------- Summary: Java 8 Epic for CDI 2.0 Key: CDI-467 URL: https://issues.jboss.org/browse/CDI-467 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Antoine Sabot-Durand Fix For: 2.0 (discussion) This Epic ticket gathers all work and documents about possible in CDI 2.0 due to Java SE 8.0 Draft document is here : https://docs.google.com/document/d/1KUaxXIXJ_r-h5UJGIij6I4vrLS7uXkeeeZr2SaRipWQ/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antoine at sabot-durand.net Fri Sep 12 10:09:29 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 12 Sep 2014 16:09:29 +0200 Subject: [cdi-dev] Workshop doc Message-ID: Hi all, So I created all the documents in Google Drive for the workshop and all the corresponding Epic tickets in Jira. I still have to link existing tickets to these Epic. Regarding the docs they?re all accessible in this drive folder : https://drive.google.com/open?id=0B2Jt7n2J0gR9TENtTnVOTC01alE&authuser=0 By default you can only read theses doc, if you want to comment them just ask. To make our life simple if you ask for one doc, we?ll give you comment right to all. Pete and I have edit right on all doc but will play the game and will avoid to write directly and use ?suggestion? mode. Now it?s time to decide if you want to take the lead on one of these workshop. I?ll start a new thread on the subject. Regards, Antoine From john.d.ament at gmail.com Fri Sep 12 10:17:11 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Fri, 12 Sep 2014 10:17:11 -0400 Subject: [cdi-dev] Workshop doc In-Reply-To: References: Message-ID: Hmm, I suppose it's going to take a little time to get all the permissions squared away. On Fri, Sep 12, 2014 at 10:09 AM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > So I created all the documents in Google Drive for the workshop and all > the corresponding Epic tickets in Jira. I still have to link existing > tickets to these Epic. > > Regarding the docs they?re all accessible in this drive folder : > https://drive.google.com/open?id=0B2Jt7n2J0gR9TENtTnVOTC01alE&authuser=0 > By default you can only read theses doc, if you want to comment them just > ask. To make our life simple if you ask for one doc, we?ll give you comment > right to all. > Pete and I have edit right on all doc but will play the game and will > avoid to write directly and use ?suggestion? mode. > > Now it?s time to decide if you want to take the lead on one of these > workshop. I?ll start a new thread on the subject. > > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140912/2051cd2a/attachment.html From antoine at sabot-durand.net Fri Sep 12 10:40:35 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 12 Sep 2014 16:40:35 +0200 Subject: [cdi-dev] Workshop doc In-Reply-To: References: Message-ID: <58474217-93FA-49AD-B698-7D4A64894325@sabot-durand.net> I hope not ;). My wish is that every one can comment or suggest something but I don?t want these to be done anonymously. Now each workshop could decide if other have comment or edit rights. Antoine > Le 12 sept. 2014 ? 16:17, John D. Ament a ?crit : > > Hmm, I suppose it's going to take a little time to get all the permissions squared away. > > On Fri, Sep 12, 2014 at 10:09 AM, Antoine Sabot-Durand > wrote: > Hi all, > > So I created all the documents in Google Drive for the workshop and all the corresponding Epic tickets in Jira. I still have to link existing tickets to these Epic. > > Regarding the docs they?re all accessible in this drive folder : https://drive.google.com/open?id=0B2Jt7n2J0gR9TENtTnVOTC01alE&authuser=0 > By default you can only read theses doc, if you want to comment them just ask. To make our life simple if you ask for one doc, we?ll give you comment right to all. > Pete and I have edit right on all doc but will play the game and will avoid to write directly and use ?suggestion? mode. > > Now it?s time to decide if you want to take the lead on one of these workshop. I?ll start a new thread on the subject. > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140912/28d93a45/attachment.html From issues at jboss.org Fri Sep 12 11:15:21 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 11:15:21 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-255) Support for Implicit Producers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-255. -------------------------------------- Fix Version/s: (was: TBD) Resolution: Done Not done in CDI but in Java EE 7. See section.EE.5.24 of the Java EE 7 specification. > Support for Implicit Producers > ------------------------------ > > Key: CDI-255 > URL: https://issues.jboss.org/browse/CDI-255 > Project: CDI Specification Issues > Issue Type: Tracker > Affects Versions: 1.0 > Reporter: Pete Muir > > An implicit producer could be registered for every unambiguous resource the Java EE container knows about. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 11:41:19 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 11:41:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-248) Provide means to observe a group of qualified events ("Qualifier Inheritance"?) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001943#comment-13001943 ] Antoine Sabot-Durand commented on CDI-248: ------------------------------------------ Could be interesting to study a way to compose qualifiers for CDI 2.0. and to evaluate this need. > Provide means to observe a group of qualified events ("Qualifier Inheritance"?) > -------------------------------------------------------------------------------- > > Key: CDI-248 > URL: https://issues.jboss.org/browse/CDI-248 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Events > Reporter: Jens Schumann > Fix For: 2.0 (discussion) > > > We have been using CDI events for application development quite extensively. For instance we use events to propagate entity lifecycle events (@Created/@Updated/@Deleted Customer customer) or GUI selections (@Selected/@Deselected Customer customer) and implement related business logic in event observers. (e.g. send email for newly created customers, clear cached values on select/deselect/create/update/delete ...). > This works quite well, however we have noticed that especially our JSF Presentation Tier contains lots of observer methods implementing the same behavior for a group of related CDI events. > Example: > {code} > public class XyzBean { > public void onCustomerCreate(@Observes @Created Customer customer) { reset();} > public void onCustomerUpdate(@Observes @Updated Customer customer) { reset();} > public void onCustomerDelete(@Observes @Deleted Customer customer) { reset();} > > } > {code} > Looks ugly, doesn't it? > The above example could be improved if CDI would be able to observe a group of qualified events, e.g. public void onCustomerLifeCycleEvent(@Observes @LifeCycleChange Customer customer) { reset(); } - ignore method and qualifier names for now. > Since Java does not support annotation inheritance grouping could be achieved using "qualified qualifier annotations": > {code} > @Qualifier > public @interface LifeCycleChange > @Qualifier > @LifeCycleChange > public @interface Created > @Qualifier > @LifeCycleChange > public @interface Updated > @Qualifier > @LifeCycleChange > public @interface Deleted > @Qualifier > public @interface SelectionChange > @Qualifier > @SelectionChange > public @interface Selected > @Qualifier > @SelectionChange > public @interface Deselected > {code} > WDYT? Side effects? Problems? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 11:41:19 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 11:41:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-248) Provide means to observe a group of qualified events ("Qualifier Inheritance"?) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-248: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Provide means to observe a group of qualified events ("Qualifier Inheritance"?) > -------------------------------------------------------------------------------- > > Key: CDI-248 > URL: https://issues.jboss.org/browse/CDI-248 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Events > Reporter: Jens Schumann > Fix For: 2.0 (discussion) > > > We have been using CDI events for application development quite extensively. For instance we use events to propagate entity lifecycle events (@Created/@Updated/@Deleted Customer customer) or GUI selections (@Selected/@Deselected Customer customer) and implement related business logic in event observers. (e.g. send email for newly created customers, clear cached values on select/deselect/create/update/delete ...). > This works quite well, however we have noticed that especially our JSF Presentation Tier contains lots of observer methods implementing the same behavior for a group of related CDI events. > Example: > {code} > public class XyzBean { > public void onCustomerCreate(@Observes @Created Customer customer) { reset();} > public void onCustomerUpdate(@Observes @Updated Customer customer) { reset();} > public void onCustomerDelete(@Observes @Deleted Customer customer) { reset();} > > } > {code} > Looks ugly, doesn't it? > The above example could be improved if CDI would be able to observe a group of qualified events, e.g. public void onCustomerLifeCycleEvent(@Observes @LifeCycleChange Customer customer) { reset(); } - ignore method and qualifier names for now. > Since Java does not support annotation inheritance grouping could be achieved using "qualified qualifier annotations": > {code} > @Qualifier > public @interface LifeCycleChange > @Qualifier > @LifeCycleChange > public @interface Created > @Qualifier > @LifeCycleChange > public @interface Updated > @Qualifier > @LifeCycleChange > public @interface Deleted > @Qualifier > public @interface SelectionChange > @Qualifier > @SelectionChange > public @interface Selected > @Qualifier > @SelectionChange > public @interface Deselected > {code} > WDYT? Side effects? Problems? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 11:44:19 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 11:44:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-270) Allow @WithAnnotations to be applied to other events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001948#comment-13001948 ] Antoine Sabot-Durand commented on CDI-270: ------------------------------------------ Not sure to understand. You want to use {{@WithAnnotation}} for other lifecycle events? > Allow @WithAnnotations to be applied to other events > ---------------------------------------------------- > > Key: CDI-270 > URL: https://issues.jboss.org/browse/CDI-270 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Labels: with-annotations > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 11:45:20 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 11:45:20 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-259) Add conversation begin and conversation end events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-259: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Add conversation begin and conversation end events > -------------------------------------------------- > > Key: CDI-259 > URL: https://issues.jboss.org/browse/CDI-259 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 11:50:19 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Sep 2014 11:50:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-114: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: 2.0 (discussion) > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 11:54:20 2014 From: issues at jboss.org (Arne Limburg (JIRA)) Date: Fri, 12 Sep 2014 11:54:20 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-460) Support repeating qualifiers in CDI SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001958#comment-13001958 ] Arne Limburg commented on CDI-460: ---------------------------------- I think, this are two different issues: First: Clarify if adding multiple Annotations of the same type is possible. Second: Add support for Annotation-Lists (like the Costraint.List feature in bean validation). > Support repeating qualifiers in CDI SPI > --------------------------------------- > > Key: CDI-460 > URL: https://issues.jboss.org/browse/CDI-460 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 2.0 (discussion) > Reporter: Antonin Stefanutti > > In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: > {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, > {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, > {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. > Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. > Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. > Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. > That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. > While that request is technically independent from Java 8, it is correlated to the support of repeating qualifiers in the typesafe resolution mechanism that is likely to be treated as part of the Java 8 stream of the CDI 2.0 specification. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 12:01:20 2014 From: issues at jboss.org (Arne Limburg (JIRA)) Date: Fri, 12 Sep 2014 12:01:20 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-468) Extend javax.interceptor.InvocationContext In-Reply-To: References: Message-ID: Arne Limburg created CDI-468: -------------------------------- Summary: Extend javax.interceptor.InvocationContext Key: CDI-468 URL: https://issues.jboss.org/browse/CDI-468 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Arne Limburg Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly. I propose to extend the javax.interceptor.InvocationContext interface with a method public Annotation getInterceptorBinding() or public A getInterceptorBinding(Class type) The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 13 07:41:19 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Sat, 13 Sep 2014 07:41:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-248) Provide means to observe a group of qualified events ("Qualifier Inheritance"?) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002109#comment-13002109 ] John Ament commented on CDI-248: -------------------------------- do you fire customers for any other reason? I'm thinking you can use [EventMetadata|http://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/spi/EventMetadata.html] to find out if an appropriate qualifier is on there. > Provide means to observe a group of qualified events ("Qualifier Inheritance"?) > -------------------------------------------------------------------------------- > > Key: CDI-248 > URL: https://issues.jboss.org/browse/CDI-248 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Events > Reporter: Jens Schumann > Fix For: 2.0 (discussion) > > > We have been using CDI events for application development quite extensively. For instance we use events to propagate entity lifecycle events (@Created/@Updated/@Deleted Customer customer) or GUI selections (@Selected/@Deselected Customer customer) and implement related business logic in event observers. (e.g. send email for newly created customers, clear cached values on select/deselect/create/update/delete ...). > This works quite well, however we have noticed that especially our JSF Presentation Tier contains lots of observer methods implementing the same behavior for a group of related CDI events. > Example: > {code} > public class XyzBean { > public void onCustomerCreate(@Observes @Created Customer customer) { reset();} > public void onCustomerUpdate(@Observes @Updated Customer customer) { reset();} > public void onCustomerDelete(@Observes @Deleted Customer customer) { reset();} > > } > {code} > Looks ugly, doesn't it? > The above example could be improved if CDI would be able to observe a group of qualified events, e.g. public void onCustomerLifeCycleEvent(@Observes @LifeCycleChange Customer customer) { reset(); } - ignore method and qualifier names for now. > Since Java does not support annotation inheritance grouping could be achieved using "qualified qualifier annotations": > {code} > @Qualifier > public @interface LifeCycleChange > @Qualifier > @LifeCycleChange > public @interface Created > @Qualifier > @LifeCycleChange > public @interface Updated > @Qualifier > @LifeCycleChange > public @interface Deleted > @Qualifier > public @interface SelectionChange > @Qualifier > @SelectionChange > public @interface Selected > @Qualifier > @SelectionChange > public @interface Deselected > {code} > WDYT? Side effects? Problems? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 13 18:18:02 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Sat, 13 Sep 2014 18:18:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-469) Allow nonbinding producer methods to have scopes In-Reply-To: References: Message-ID: John Ament created CDI-469: ------------------------------ Summary: Allow nonbinding producer methods to have scopes Key: CDI-469 URL: https://issues.jboss.org/browse/CDI-469 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans, Contexts Affects Versions: 1.2.Final Reporter: John Ament Currently, you cannot have a nonbinding producer method, e.g. one where the annotation is read at runtime, with a scope. This means that repeated injections always happen. It would be better if you could scope the nonbinding producer methods, so that the results were bound, e.g. to a request scope, so that look ups can be done once. The current way to avoid this is to use a holder object with the proper scope. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 14 02:21:02 2014 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Sun, 14 Sep 2014 02:21:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-470) Clarify @Vetoed on recursive package In-Reply-To: References: Message-ID: Antonio Goncalves created CDI-470: ------------------------------------- Summary: Clarify @Vetoed on recursive package Key: CDI-470 URL: https://issues.jboss.org/browse/CDI-470 Project: CDI Specification Issues Issue Type: Clarification Components: Beans Affects Versions: 1.2.Final Reporter: Antonio Goncalves It's not clear in the specification is {{@Vetoed}} only apply to the current package or subpackages as well. This has been addressed on [CDI-299] but not solved. Either, we make it clearer in the spec that it only addresses the current package and not subpackages, or we could have a boolean, such as {{recursive}} : {code:title=package-info.java} @Vetoed(recursive=true) package my.parent.package; import javax.enterprise.inject.Vetoed; {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 02:57:02 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 15 Sep 2014 02:57:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-470) Clarify @Vetoed on recursive package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002163#comment-13002163 ] Martin Kouba commented on CDI-470: ---------------------------------- In my opinion, it is clear that {{@Vetoed}} only applies to the "current package". The spec simply states that the class must be "in a package": {quote} A top-level Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions: * ... * It is not annotated @Vetoed or in a package annotated @Vetoed. * ... {quote} See also "3.1.1. Which Java classes are managed beans" (and similarly for session beans). AFAIK the Java lang does not define the relation between the package and its subpackages from the visibility point of view, nor provides a Reflection API to work with subpackages. > Clarify @Vetoed on recursive package > ------------------------------------ > > Key: CDI-470 > URL: https://issues.jboss.org/browse/CDI-470 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.2.Final > Reporter: Antonio Goncalves > > It's not clear in the specification is {{@Vetoed}} only apply to the current package or subpackages as well. This has been addressed on [CDI-299] but not solved. Either, we make it clearer in the spec that it only addresses the current package and not subpackages, or we could have a boolean, such as {{recursive}} : > {code:title=package-info.java} > @Vetoed(recursive=true) > package my.parent.package; > import javax.enterprise.inject.Vetoed; > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 03:02:02 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 15 Sep 2014 03:02:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-469) Allow nonbinding producer methods to have scopes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002164#comment-13002164 ] Martin Kouba commented on CDI-469: ---------------------------------- [~meetoblivion] I'm sorry but I don't follow you. Could you be more specific about what "nonbinding producer method" means? Simple example would be helpful as well ;-) > Allow nonbinding producer methods to have scopes > ------------------------------------------------ > > Key: CDI-469 > URL: https://issues.jboss.org/browse/CDI-469 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Contexts > Affects Versions: 1.2.Final > Reporter: John Ament > > Currently, you cannot have a nonbinding producer method, e.g. one where the annotation is read at runtime, with a scope. This means that repeated injections always happen. It would be better if you could scope the nonbinding producer methods, so that the results were bound, e.g. to a request scope, so that look ups can be done once. > The current way to avoid this is to use a holder object with the proper scope. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 03:23:02 2014 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Mon, 15 Sep 2014 03:23:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-470) Clarify @Vetoed on recursive package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002171#comment-13002171 ] Antonio Goncalves commented on CDI-470: --------------------------------------- Hum... not that clear to me, but well. Shall it stay like that ? I tend to add a package-level {{@Veto}} on my entities ({{org.mystuff.model}})... but in big projects my model is usually spllitted into sub packages ({{org.mystuff.model.customer}}, {{org.mystuff.model.order}}, ...). Recursive veto would be interesting. Any thoughts ? > Clarify @Vetoed on recursive package > ------------------------------------ > > Key: CDI-470 > URL: https://issues.jboss.org/browse/CDI-470 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.2.Final > Reporter: Antonio Goncalves > > It's not clear in the specification is {{@Vetoed}} only apply to the current package or subpackages as well. This has been addressed on [CDI-299] but not solved. Either, we make it clearer in the spec that it only addresses the current package and not subpackages, or we could have a boolean, such as {{recursive}} : > {code:title=package-info.java} > @Vetoed(recursive=true) > package my.parent.package; > import javax.enterprise.inject.Vetoed; > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 03:28:02 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 15 Sep 2014 03:28:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-470) Clarify @Vetoed on recursive package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002173#comment-13002173 ] Romain Manni-Bucau commented on CDI-470: ---------------------------------------- Hmm for me it was logical that it was the opposite otherwise it is clearly too impacting when a project is well organized at package level. scan block in beans.xml has .**, annotation should get it as well no? > Clarify @Vetoed on recursive package > ------------------------------------ > > Key: CDI-470 > URL: https://issues.jboss.org/browse/CDI-470 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.2.Final > Reporter: Antonio Goncalves > > It's not clear in the specification is {{@Vetoed}} only apply to the current package or subpackages as well. This has been addressed on [CDI-299] but not solved. Either, we make it clearer in the spec that it only addresses the current package and not subpackages, or we could have a boolean, such as {{recursive}} : > {code:title=package-info.java} > @Vetoed(recursive=true) > package my.parent.package; > import javax.enterprise.inject.Vetoed; > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 03:32:02 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 15 Sep 2014 03:32:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-470) Clarify @Vetoed on recursive package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002175#comment-13002175 ] Martin Kouba commented on CDI-470: ---------------------------------- Yes, something like this sounds reasonable. Right now, you can only use exclude filters in beans.xml or a portable extension and {{ProcessAnnotatedType.veto()}}. But it's not that practical. What I'm trying to say is that it's not a perfect match to use an annotation on a package to affect the subpackages. > Clarify @Vetoed on recursive package > ------------------------------------ > > Key: CDI-470 > URL: https://issues.jboss.org/browse/CDI-470 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.2.Final > Reporter: Antonio Goncalves > > It's not clear in the specification is {{@Vetoed}} only apply to the current package or subpackages as well. This has been addressed on [CDI-299] but not solved. Either, we make it clearer in the spec that it only addresses the current package and not subpackages, or we could have a boolean, such as {{recursive}} : > {code:title=package-info.java} > @Vetoed(recursive=true) > package my.parent.package; > import javax.enterprise.inject.Vetoed; > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 03:47:02 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 15 Sep 2014 03:47:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-255) Support for Implicit Producers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002179#comment-13002179 ] Martin Kouba commented on CDI-255: ---------------------------------- [~antoinesabot-durand] I'm not sure which part of "EE.5.24 Support for Dependency Injection" is relevant... > Support for Implicit Producers > ------------------------------ > > Key: CDI-255 > URL: https://issues.jboss.org/browse/CDI-255 > Project: CDI Specification Issues > Issue Type: Tracker > Affects Versions: 1.0 > Reporter: Pete Muir > > An implicit producer could be registered for every unambiguous resource the Java EE container knows about. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antoine at sabot-durand.net Mon Sep 15 04:03:56 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 15 Sep 2014 10:03:56 +0200 Subject: [cdi-dev] Workshops leaders and members raise you hand Message-ID: <996CDD5C-C7D7-409E-8308-7AC41402C859@sabot-durand.net> Hi all, As you may have sawn, I created the docs and Jira Epic tickets associated with major workshops. Those Epic tickets are here : https://issues.jboss.org/browse/CDI-467?filter=12322370 Now it?s time to get started. If you have a rather good knowledge of CDI and have a vision of one of these workshop, you can volunteer to lead one. The role consist to write a draft on the subject. This draft will be a starting point for discussion. The workshop leader may also organise meetings if he feels it necessary. It shouldn?t take you a lot of time and this role can be taken by two people if you don?t like being alone. This role is not definitive and if in a near future you lack time to pursue it, just tell and someone else will step in. Workshop members are people interested on the subject and ready to contribute with ideas or help for the leader. All community member can be part of these workshop. But to have a better idea of our work force, people who want to be part of one or more workshop should let us know : we won?t deliver the same content if we are 5 or 15... Anyway, Pete and/or I will be part of all workshops and lead those that didn?t find another leader. Remember that we imagined this organisation to ease community participation and casual contribution. So don?t be shy, it?s time to tell us your commitment to CDI ;). Antoine From mkouba at redhat.com Mon Sep 15 04:25:44 2014 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 15 Sep 2014 10:25:44 +0200 Subject: [cdi-dev] Workshops leaders and members raise you hand In-Reply-To: <996CDD5C-C7D7-409E-8308-7AC41402C859@sabot-durand.net> References: <996CDD5C-C7D7-409E-8308-7AC41402C859@sabot-durand.net> Message-ID: <5416A288.7070602@redhat.com> If you don't use the "Detail view" when searching issues (but the "List view" like me ;-), this is the correct link: https://issues.jboss.org/issues/?filter=12322370 M Dne 15.9.2014 v 10:03 Antoine Sabot-Durand napsal(a): > Hi all, > > As you may have sawn, I created the docs and Jira Epic tickets associated with major workshops. > > Those Epic tickets are here : > > https://issues.jboss.org/browse/CDI-467?filter=12322370 > > Now it?s time to get started. > > If you have a rather good knowledge of CDI and have a vision of one of these workshop, you can volunteer to lead one. The role consist to write a draft on the subject. This draft will be a starting point for discussion. The workshop leader may also organise meetings if he feels it necessary. It shouldn?t take you a lot of time and this role can be taken by two people if you don?t like being alone. This role is not definitive and if in a near future you lack time to pursue it, just tell and someone else will step in. > > Workshop members are people interested on the subject and ready to contribute with ideas or help for the leader. All community member can be part of these workshop. But to have a better idea of our work force, people who want to be part of one or more workshop should let us know : we won?t deliver the same content if we are 5 or 15... > > Anyway, Pete and/or I will be part of all workshops and lead those that didn?t find another leader. > > Remember that we imagined this organisation to ease community participation and casual contribution. So don?t be shy, it?s time to tell us your commitment to CDI ;). > > 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 issues at jboss.org Mon Sep 15 04:57:02 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 15 Sep 2014 04:57:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism In-Reply-To: References: Message-ID: Antonin Stefanutti created CDI-471: -------------------------------------- Summary: Support repeating qualifiers in typesafe resolution mechanism Key: CDI-471 URL: https://issues.jboss.org/browse/CDI-471 Project: CDI Specification Issues Issue Type: Feature Request Components: Resolution Reporter: Antonin Stefanutti As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism. For example, one could write: {code} @Qualifier @Repeatable(ContextNames.class) public interface @ContextName { String value; } public @interface ContextNames { ContextName[] value(); } {code} And then: {code} @ContextName("ctx1") class CamelContext1 { } @ContextName("ctx2") class CamelContext2 { } @Uri("") @Produces @ContextName("ctx1") @ContextName("ctx2") static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance instance) { } {code} That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies. Support of the annotation container / list for backward compatibility could be provided as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 05:00:02 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 15 Sep 2014 05:00:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-460) Support repeating annotations in CDI SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated CDI-460: ----------------------------------- Summary: Support repeating annotations in CDI SPI (was: Support repeating qualifiers in CDI SPI) > Support repeating annotations in CDI SPI > ---------------------------------------- > > Key: CDI-460 > URL: https://issues.jboss.org/browse/CDI-460 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 2.0 (discussion) > Reporter: Antonin Stefanutti > > In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: > {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, > {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, > {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. > Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. > Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. > Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. > That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. > While that request is technically independent from Java 8, it is correlated to the support of repeating qualifiers in the typesafe resolution mechanism that is likely to be treated as part of the Java 8 stream of the CDI 2.0 specification. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 05:03:02 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 15 Sep 2014 05:03:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-460) Support repeating annotations in CDI SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002218#comment-13002218 ] Antonin Stefanutti commented on CDI-460: ---------------------------------------- [~arnelim] I agree with you. I've just created [CDI-471] to track that second issue, that is the support at the level of the typesafe resolution of repeating qualifiers and container / list annotations as well. > Support repeating annotations in CDI SPI > ---------------------------------------- > > Key: CDI-460 > URL: https://issues.jboss.org/browse/CDI-460 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 2.0 (discussion) > Reporter: Antonin Stefanutti > > In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: > {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, > {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, > {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. > Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. > Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. > Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. > That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. > While that request is technically independent from Java 8, it is correlated to the support of repeating qualifiers in the typesafe resolution mechanism that is likely to be treated as part of the Java 8 stream of the CDI 2.0 specification. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 05:28:02 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 15 Sep 2014 05:28:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-472) Support @WithAnnotations as type annotation of lifecycle events In-Reply-To: References: Message-ID: Antonin Stefanutti created CDI-472: -------------------------------------- Summary: Support @WithAnnotations as type annotation of lifecycle events Key: CDI-472 URL: https://issues.jboss.org/browse/CDI-472 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Antonin Stefanutti As Java 8 introduces type annotations, generalizing the benefit of {{@WithAnnotations}} by using it as type annotation could improve a lot of recurring patterns that are usually implemented as a combination of {{ProcessAnnotatedType}} and other lifecycle events. For example, instead of having to write that in a CDI extension: {code} Set> camelBeans = new HashMap<>(); void camelAnnotations(@Observes @WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) ProcessAnnotatedType pat) { camelBeans.add(pat.getAnnotatedType()); } void camelBeansPostProcessor(@Observes ProcessInjectionTarget pit, BeanManager manager) { if (camelBeans.contains(pit.getAnnotatedType())) pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager)); } {code} One could write directly: {code} <@WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) T> void camelBeansPostProcessor(@Observes ProcessInjectionTarget pit, BeanManager manager) { pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager)); } {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 05:31:02 2014 From: issues at jboss.org (Pete Muir (JIRA)) Date: Mon, 15 Sep 2014 05:31:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002234#comment-13002234 ] Pete Muir commented on CDI-471: ------------------------------- +1 this will make CDI easier to use. > Support repeating qualifiers in typesafe resolution mechanism > ------------------------------------------------------------- > > Key: CDI-471 > URL: https://issues.jboss.org/browse/CDI-471 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Reporter: Antonin Stefanutti > > As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism. > For example, one could write: > {code} > @Qualifier > @Repeatable(ContextNames.class) > public interface @ContextName { > String value; > } > public @interface ContextNames { > ContextName[] value(); > } > {code} > And then: > {code} > @ContextName("ctx1") > class CamelContext1 { > } > @ContextName("ctx2") > class CamelContext2 { > } > @Uri("") > @Produces > @ContextName("ctx1") > @ContextName("ctx2") > static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance instance) { > } > {code} > That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies. > Support of the annotation container / list for backward compatibility could be provided as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 05:37:02 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 15 Sep 2014 05:37:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-472) Support @WithAnnotations as type annotation of lifecycle events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated CDI-472: ----------------------------------- Description: As Java 8 introduces type annotations, generalizing the benefit of {{@WithAnnotations}} by using it as type annotation could improve a lot of recurring patterns that are usually implemented as a combination of {{ProcessAnnotatedType}} and other lifecycle events. For example, instead of having to write that in a CDI extension: {code} Set> camelBeans = new HashMap<>(); void camelAnnotations(@Observes @WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) ProcessAnnotatedType pat) { camelBeans.add(pat.getAnnotatedType()); } void camelBeansPostProcessor(@Observes ProcessInjectionTarget pit, BeanManager manager) { if (camelBeans.contains(pit.getAnnotatedType())) pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager)); } {code} One could write directly: {code} <@WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) T> void camelBeansPostProcessor(@Observes ProcessInjectionTarget pit, BeanManager manager) { pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager)); } {code} was: As Java 8 introduces type annotations, generalizing the benefit of {{@WithAnnotations}} by using it as type annotation could improve a lot of recurring patterns that are usually implemented as a combination of {{ProcessAnnotatedType}} and other lifecycle events. For example, instead of having to write that in a CDI extension: {code} Set> camelBeans = new HashMap<>(); void camelAnnotations(@Observes @WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) ProcessAnnotatedType pat) { camelBeans.add(pat.getAnnotatedType()); } void camelBeansPostProcessor(@Observes ProcessInjectionTarget pit, BeanManager manager) { if (camelBeans.contains(pit.getAnnotatedType())) pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager)); } {code} One could write directly: {code} <@WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) T> void camelBeansPostProcessor(@Observes ProcessInjectionTarget pit, BeanManager manager) { pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager)); } {code} > Support @WithAnnotations as type annotation of lifecycle events > --------------------------------------------------------------- > > Key: CDI-472 > URL: https://issues.jboss.org/browse/CDI-472 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antonin Stefanutti > > As Java 8 introduces type annotations, generalizing the benefit of {{@WithAnnotations}} by using it as type annotation could improve a lot of recurring patterns that are usually implemented as a combination of {{ProcessAnnotatedType}} and other lifecycle events. > For example, instead of having to write that in a CDI extension: > {code} > Set> camelBeans = new HashMap<>(); > void camelAnnotations(@Observes @WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) ProcessAnnotatedType pat) { > camelBeans.add(pat.getAnnotatedType()); > } > void camelBeansPostProcessor(@Observes ProcessInjectionTarget pit, BeanManager manager) { > if (camelBeans.contains(pit.getAnnotatedType())) > pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager)); > } > {code} > One could write directly: > {code} > <@WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) T> void camelBeansPostProcessor(@Observes ProcessInjectionTarget pit, BeanManager manager) { > pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager)); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 05:49:04 2014 From: issues at jboss.org (Pete Muir (JIRA)) Date: Mon, 15 Sep 2014 05:49:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-255) Support for Implicit Producers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002247#comment-13002247 ] Pete Muir commented on CDI-255: ------------------------------- This wasn't done in Java EE 7. > Support for Implicit Producers > ------------------------------ > > Key: CDI-255 > URL: https://issues.jboss.org/browse/CDI-255 > Project: CDI Specification Issues > Issue Type: Tracker > Affects Versions: 1.0 > Reporter: Pete Muir > > An implicit producer could be registered for every unambiguous resource the Java EE container knows about. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 05:49:04 2014 From: issues at jboss.org (Pete Muir (JIRA)) Date: Mon, 15 Sep 2014 05:49:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-255) Support for Implicit Producers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir reopened CDI-255: --------------------------- > Support for Implicit Producers > ------------------------------ > > Key: CDI-255 > URL: https://issues.jboss.org/browse/CDI-255 > Project: CDI Specification Issues > Issue Type: Tracker > Affects Versions: 1.0 > Reporter: Pete Muir > > An implicit producer could be registered for every unambiguous resource the Java EE container knows about. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 05:54:02 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 15 Sep 2014 05:54:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: Antonin Stefanutti created CDI-473: -------------------------------------- Summary: Standardize eager initialisation of ApplicationScoped bean Key: CDI-473 URL: https://issues.jboss.org/browse/CDI-473 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Reporter: Antonin Stefanutti Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: {code} void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { for (AnnotatedType type : eagerBeans) // Calling toString is necessary to force the initialization of normal-scoped beans BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); } {code} There should be a concise way to declare that intent which would then be address by the CDI container, for example: {code} @ApplicationScoped(eager = true} class EagerApplicationScopedBean { } {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 05:59:02 2014 From: issues at jboss.org (Pete Muir (JIRA)) Date: Mon, 15 Sep 2014 05:59:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-470) Clarify @Vetoed on recursive package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002253#comment-13002253 ] Pete Muir commented on CDI-470: ------------------------------- It only applies to the current package, and not to subpackages. Taxonomically, Java does not define subpackages as a type of package, but as a unique indentity - take a look the Java Language Specification. However, in common usage, this definition has become blurred, so I think we could add a note to the spec here, that makes this point. Recursive vetoing is possibly interesting, but note that the note {quote} When placed on package, all beans in the package are prevented from being installed. If packages are split across jars, non-portable behavior results. An application can prevent packages being split across jars by sealing the package {quote} would need to apply to subpackage. IOW all packages and subpackages must be in the same JAR. Java provides no way to enforce this unfortunately. > Clarify @Vetoed on recursive package > ------------------------------------ > > Key: CDI-470 > URL: https://issues.jboss.org/browse/CDI-470 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.2.Final > Reporter: Antonio Goncalves > > It's not clear in the specification is {{@Vetoed}} only apply to the current package or subpackages as well. This has been addressed on [CDI-299] but not solved. Either, we make it clearer in the spec that it only addresses the current package and not subpackages, or we could have a boolean, such as {{recursive}} : > {code:title=package-info.java} > @Vetoed(recursive=true) > package my.parent.package; > import javax.enterprise.inject.Vetoed; > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 06:06:02 2014 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Mon, 15 Sep 2014 06:06:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002257#comment-13002257 ] Antonio Goncalves commented on CDI-473: --------------------------------------- What about using {{@Startup}} in this case ? One idea in Java EE 7 was to take the [{{javax.ejb.Startup}}|http://docs.oracle.com/javaee/7/api/javax/ejb/Startup.html] annotation out of the EJB spec, and give this functionality to every managed bean (even a servlet). This wasn't done... unfortunately. For Java EE 8, hopefully, we will be able to have such startup behavior back into the [Concurrency Utilities for Java EE|https://jcp.org/en/jsr/detail?id=236] where it would make more sense. > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 06:13:02 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 15 Sep 2014 06:13:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002265#comment-13002265 ] Antonin Stefanutti commented on CDI-473: ---------------------------------------- Indeed, {{@Startup}} may be a candidate. I see two questions in order to determine the best way to capture that: * Does that apply to {{ApplicationScoped}} bean only? * It that worth enough to depend on an other specification for that purpose only? > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 06:25:03 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 06:25:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-255) Support for Implicit Producers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002279#comment-13002279 ] Antoine Sabot-Durand commented on CDI-255: ------------------------------------------ Yes you're right, sorry for the mistake. Anyway don't you think this should be in EE 8 spec not CDI ? > Support for Implicit Producers > ------------------------------ > > Key: CDI-255 > URL: https://issues.jboss.org/browse/CDI-255 > Project: CDI Specification Issues > Issue Type: Tracker > Affects Versions: 1.0 > Reporter: Pete Muir > > An implicit producer could be registered for every unambiguous resource the Java EE container knows about. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 06:28:02 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 15 Sep 2014 06:28:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-474) Enrich AnnotatedParameter to get access to parameter name In-Reply-To: References: Message-ID: Antonin Stefanutti created CDI-474: -------------------------------------- Summary: Enrich AnnotatedParameter to get access to parameter name Key: CDI-474 URL: https://issues.jboss.org/browse/CDI-474 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Reporter: Antonin Stefanutti With [JEP 118|http://openjdk.java.net/jeps/118] (Access to Parameter Names at Runtime) introduced in Java 8, the CDI SPI could be enriched so that {{AnnotatedParameter}} provide access to parameter names of methods and constructors. In addition to class and method names that are used for default naming convention in producer methods that rely on {{InjectionPoint}} metadata, parameter name could be used as well to implement default convention for method parameter injection point. One example of such a pattern is implemented in the [Metrics CDI extension|https://github.com/astefanutti/metrics-cdi#metrics-injection] and that would avoid to rely on the Java API: https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java/io/astefanutti/metrics/cdi/MetricProducer.java#L126. That is something Spring 4 now provides with [SPR-9643|https://jira.spring.io/browse/SPR-9643]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 07:20:02 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Mon, 15 Sep 2014 07:20:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002302#comment-13002302 ] Jozef Hartinger commented on CDI-473: ------------------------------------- Note that this can currently be done by: {code:JAVA} @ApplicationScoped public class Foo { void init(@Observes @Initialized(ApplicationScoped.class) Object event) { // init } } {code} > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 07:57:05 2014 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Mon, 15 Sep 2014 07:57:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-255) Support for Implicit Producers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002319#comment-13002319 ] Antonio Goncalves commented on CDI-255: --------------------------------------- When you look at all the Java EE 7 specs, you don't find much : *Bean Validation 1.1* (? 10.3. Context and Dependency Injection (CDI) integration) {code} @Inject ValidatorFactory; @Inject Validator; {code} *JMS 2.0* (? 12.4.3. Injection syntax) {code} @Inject private JMSContext context; {code} So definitely a section on Java EE about implicit producers BTW, in the Java EE 7 spec there is *only one single* line of code showing {{@Inject}} > Support for Implicit Producers > ------------------------------ > > Key: CDI-255 > URL: https://issues.jboss.org/browse/CDI-255 > Project: CDI Specification Issues > Issue Type: Tracker > Affects Versions: 1.0 > Reporter: Pete Muir > > An implicit producer could be registered for every unambiguous resource the Java EE container knows about. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:00:16 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 15 Sep 2014 08:00:16 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-469) Allow nonbinding producer methods to have scopes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002322#comment-13002322 ] John Ament commented on CDI-469: -------------------------------- Sure, suppose I have this qualifier: {code:java} @Qualifier ... public @interface Converter { @Nonbind String value(); } {code} I can define a producer field like so: {code:java} @Produces @ApplicationScoped @Converter("fooAtoB") private Function aToBConv = new AToBFunction(); {code} If however these were lazily instantiated, or I had a map or looked up values via DB call, I need to add a producer method. In this case, I want it to be generic and reusable, however the instances that it returns should be proxied, scope aware (e.g. not unique for each invocation, as is the current behaviour). {code:java} @Produces @Converter // @ApplicationScoped <-- scope is not valid here public Function createOrFindFunction(InjectionPoint ip) { // work to look up the function } {code} Scope isnt' valid here as the injection point could be different. What I'm proposing is that we lift this restriction, in cases where the qualifiers are the same. > Allow nonbinding producer methods to have scopes > ------------------------------------------------ > > Key: CDI-469 > URL: https://issues.jboss.org/browse/CDI-469 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Contexts > Affects Versions: 1.2.Final > Reporter: John Ament > > Currently, you cannot have a nonbinding producer method, e.g. one where the annotation is read at runtime, with a scope. This means that repeated injections always happen. It would be better if you could scope the nonbinding producer methods, so that the results were bound, e.g. to a request scope, so that look ups can be done once. > The current way to avoid this is to use a holder object with the proper scope. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:04:02 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 15 Sep 2014 08:04:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002325#comment-13002325 ] John Ament commented on CDI-473: -------------------------------- There are some downsides to using Initialized, if not done safely. For one, you don't want to do the initialization logic in there unless you're ok with it being done multiple times (since anyone can fire this event). It's better to still put it in PostConstruct, and leave this method as is. Which begs the question, is there a benefit to having empty methods just to declare observers? > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:12:03 2014 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Mon, 15 Sep 2014 08:12:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002328#comment-13002328 ] Antonio Goncalves commented on CDI-414: --------------------------------------- BTW, nowhere in the Interceptor 1.2 spec we find the word "proxy" or "public vs private method" interception. Interceptor 1.2 does not really specify that only private methods should not be intercepted. On the other hand, the specification uses the term *business method*. No definition of what a *business method* is in the Interceptor spec. But because interceptors come from the EJB world, if we look at the EJB spec, we can read : {quote} 3.2 - Local, Remote, and Web Service Client Views The term business method is used to refer to a method of an enterprise bean that is available for client execution. It may be a method exposed by the local or remote business interface, by the no-interface view, by the local component interface, by the remote component interface, or by the web service client view. {quote} So, in the EJB 3.2 spec it is clearly said that private method are not intercepted, but it's not clear in Interceptor 1.2 > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:32:03 2014 From: issues at jboss.org (Pete Muir (JIRA)) Date: Mon, 15 Sep 2014 08:32:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002336#comment-13002336 ] Pete Muir commented on CDI-414: ------------------------------- CDI also defines business methods to not include private methods. > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:03:05 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 09:03:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002354#comment-13002354 ] Antoine Sabot-Durand commented on CDI-414: ------------------------------------------ @agoncal, The reference is here : http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method. The last sentence is the important part here (I missed it before) : {quote} Otherwise, the invocation is treated as a normal Java method call and is not intercepted by the container. {quote} So the fact that inner calls shouldn't be intercepted or decorated doesn't come from interceptor spec but from CDI spec itself. We could imagine change that : keep this default behaviour and add an option that could activate AOP on inner calls. > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:03:06 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 09:03:06 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002354#comment-13002354 ] Antoine Sabot-Durand edited comment on CDI-414 at 9/15/14 9:02 AM: ------------------------------------------------------------------- [~agoncal], The reference is here : http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method. The last sentence is the important part here (I missed it before) : {quote} Otherwise, the invocation is treated as a normal Java method call and is not intercepted by the container. {quote} So the fact that inner calls shouldn't be intercepted or decorated doesn't come from interceptor spec but from CDI spec itself. We could imagine change that : keep this default behaviour and add an option that could activate AOP on inner calls. was (Author: antoinesabot-durand): @agoncal, The reference is here : http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method. The last sentence is the important part here (I missed it before) : {quote} Otherwise, the invocation is treated as a normal Java method call and is not intercepted by the container. {quote} So the fact that inner calls shouldn't be intercepted or decorated doesn't come from interceptor spec but from CDI spec itself. We could imagine change that : keep this default behaviour and add an option that could activate AOP on inner calls. > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:05:02 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 15 Sep 2014 09:05:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-475) Support type annotation in assignability of parameterized types In-Reply-To: References: Message-ID: Antonin Stefanutti created CDI-475: -------------------------------------- Summary: Support type annotation in assignability of parameterized types Key: CDI-475 URL: https://issues.jboss.org/browse/CDI-475 Project: CDI Specification Issues Issue Type: Feature Request Components: Resolution Reporter: Antonin Stefanutti Since Java 8 provides support for type annotations, the assignability of parameterized types rules could be updated to support that feature that may add value in a number of use cases. For example, with lifecycle events resolution, instead of writing: {code} Set contextNames = new HashSet<>(); void camelContextNames(@Observes ProcessAnnotatedType pat) { if (pat.getAnnotatedType().isAnnotationPresent(ContextName.class)) contextNames.add(pat.getAnnotatedType().getAnnotation(ContextName.class)); } {code} One could directly write: {code} void camelContextNames(@Observes ProcessAnnotatedType<@ContextName ? extends CamelContext> pat) { contextNames.add(pat.getAnnotatedType().getAnnotation(ContextName.class)); } {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:07:03 2014 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Mon, 15 Sep 2014 09:07:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002356#comment-13002356 ] Antonio Goncalves commented on CDI-414: --------------------------------------- [~antoinesabot-durand] Again, I would take that to the Java EE expert group. It would be strange to have CDI beans private methods intercepted, and not all the other components (EJBs...). That's why I think that this behaviour should be common to all components, therefore, specified in the Interceptor spec > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:31:04 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 09:31:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002374#comment-13002374 ] Antoine Sabot-Durand commented on CDI-414: ------------------------------------------ You're right [~agoncal]. But if we decide go that way we should propose something nicely design for *interceptors* and *decorators*. To satisfy this there are two obvious solutions IMO. # enhance an annotation used by both mechanism. {{@Priority}} seems the only candidate here, or # introduce an new annotation in interceptor spec to configure this behaviour on the bean or the interceptor / Decorator. Something like {{@InterceptorAttribute}} with different values (in the same spirit than {{@TransactionAttibute}} in EJB spec) I prefer solution 2 since this annotation could be put at different levels. wdyt? > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:37:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 09:37:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-366) wrong version in javadoc In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-366. ------------------------------------ Resolution: Duplicate Issue > wrong version in javadoc > ------------------------ > > Key: CDI-366 > URL: https://issues.jboss.org/browse/CDI-366 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.1.PFD > Reporter: Gerhard Petracek > Fix For: TBD > > > commit 0dbe4a7fe7f3ed1a2d4c4b3ab08e641d39277731 changed @since from 1.1 to 1.2-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:44:04 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 09:44:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-362) No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-362: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting > --------------------------------------------------------------------------------------------- > > Key: CDI-362 > URL: https://issues.jboss.org/browse/CDI-362 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > > E.g. > // allowed by EJB > // disallowed by CDI > @Stateful @RequestScoped > public class MyBean { > final void m() { }; > } > public class Other { > @EJB MyBean field; // PASS > @Inject MyBean field; // FAIL - unproxyable > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:50:04 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 09:50:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-291) Clarify interceptor/decorator resolution rules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-291: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Clarify interceptor/decorator resolution rules > ---------------------------------------------- > > Key: CDI-291 > URL: https://issues.jboss.org/browse/CDI-291 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.0 > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 2.0 (discussion) > > > Currently the spec only says: > {quote} > A decorator is bound to a bean if: > * The bean is assignable to the delegate injection point according to the rules defined in Section 5.2, "Typesafe resolu- > tion" (using Section 8.3.1, "Assignability of raw and parameterized types for delegate injection points"). > * The decorator is enabled in the bean archive containing the bean. > {quote} > AND > {quote} > An interceptor is bound to a method if: > * The method has all the interceptor bindings of the interceptor. A method has an interceptor binding of an interceptor if > it has an interceptor binding with (a) the same type and (b) the same annotation member value for each member which > is not annotated @javax.enterprise.util.Nonbinding. > * The interceptor intercepts the given kind of lifecycle callback or business method. > * The interceptor is enabled in the bean archive containing the bean. > {quote} > What remains unspecified is: > * In a scenario where a module A enables interceptor X in its beans.xml, does X have to be accessible from A. That effectively means that an EJB jar could (or could not) legally use an interceptor/decorator packaged in a web application. > * Even if X is accessible, does it have to be packaged in a bean archive or is it enough for it to be packaged in a library that does not contain beans.xml but is accessible from A? This means that a CDI implementation would need to additionally scan those classes as they would not be scanned by normal bean archive discovery. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:55:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 09:55:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-280: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > clarify usage of 'bean' term usage in the spec > ---------------------------------------------- > > Key: CDI-280 > URL: https://issues.jboss.org/browse/CDI-280 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: CDI_api_chge, CDI_spec_chge > Fix For: 2.0 (discussion) > > > We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for > * The Bean extends Contextual. Should be referred as 'Bean' or 'CDI Bean' > * The class which gets scanned. Should be referred as 'Bean Class' to > * The instance stored in the context. Should be referred to as 'Contextual Instance' > * The proxy for a Contextual Instance should be referred to as 'Contextual Reference' > * The type of an injection point should be referred to as 'InjectionPoint Type' -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:59:02 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 15 Sep 2014 09:59:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-476) Inheritance of private observer and initializer methods In-Reply-To: References: Message-ID: Martin Kouba created CDI-476: -------------------------------- Summary: Inheritance of private observer and initializer methods Key: CDI-476 URL: https://issues.jboss.org/browse/CDI-476 Project: CDI Specification Issues Issue Type: Clarification Components: Inheritance and Specialization Affects Versions: 1.2.Final Reporter: Martin Kouba Initializer and observer methods may be private. In Java, private members are not inherited. However, the spec is not entirely clear in this area. "4. Inheritance and specialization" {quote} Member-level metadata is not inherited. However, injected fields, initializer methods, lifecycle callback methods and non-static observer methods are inherited by beans from their superclasses. {quote} "4.2. Inheritance of member-level metadata" (simplified): {quote} * If X declares an initializer or non-static observer method x() then Y inherits x() if and only if neither Y nor any intermediate class that is a subclass of X and a superclass of Y overrides the method x(). {quote} There is no mention we strictly follow the JSL here. At first glance, it seems the private members should not be inherited. However, these may be part of a bean initialization. And what happens if we *specialize* a bean with such private members? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:17:02 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 15 Sep 2014 10:17:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java in javax.enterprise.inject package In-Reply-To: References: Message-ID: Martin Kouba created CDI-477: -------------------------------- Summary: Update outdated package-info.java in javax.enterprise.inject package Key: CDI-477 URL: https://issues.jboss.org/browse/CDI-477 Project: CDI Specification Issues Issue Type: Bug Components: Javadoc and API Affects Versions: 1.2.Final Reporter: Martin Kouba Update or remove this javadoc. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:48:03 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 10:48:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-478) Interceptor and Decorator EPIC for CDI 2.0 In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-478: ---------------------------------------- Summary: Interceptor and Decorator EPIC for CDI 2.0 Key: CDI-478 URL: https://issues.jboss.org/browse/CDI-478 Project: CDI Specification Issues Issue Type: Epic Reporter: Antoine Sabot-Durand This Epic ticket gathers all work and documents about interceptor and decorator in CDI 2.0 Draft document is here : https://docs.google.com/document/d/10iexiDfMT9tYaUPa2cGiw4P68VG_bryDIS0DKzP1ils/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:50:03 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 15 Sep 2014 10:50:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-469) Allow nonbinding producer methods to have scopes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002444#comment-13002444 ] Martin Kouba commented on CDI-469: ---------------------------------- I think you can't relax this restriction as the InjectionPoint is not only about required type and qualifiers. There's bean, member info, etc. As a workaround you could have a separate @ApplicationScoped bean which takes the {{Converted#value()}} as a param and performs the lookup. > Allow nonbinding producer methods to have scopes > ------------------------------------------------ > > Key: CDI-469 > URL: https://issues.jboss.org/browse/CDI-469 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Contexts > Affects Versions: 1.2.Final > Reporter: John Ament > > Currently, you cannot have a nonbinding producer method, e.g. one where the annotation is read at runtime, with a scope. This means that repeated injections always happen. It would be better if you could scope the nonbinding producer methods, so that the results were bound, e.g. to a request scope, so that look ups can be done once. > The current way to avoid this is to use a holder object with the proper scope. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:52:03 2014 From: issues at jboss.org (Pete Muir (JIRA)) Date: Mon, 15 Sep 2014 10:52:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-469) Allow nonbinding producer methods to have scopes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002448#comment-13002448 ] Pete Muir commented on CDI-469: ------------------------------- The injection point isn't valid there, even if the qualifiers are the same. I still don't really understand what you are asking for. > Allow nonbinding producer methods to have scopes > ------------------------------------------------ > > Key: CDI-469 > URL: https://issues.jboss.org/browse/CDI-469 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Contexts > Affects Versions: 1.2.Final > Reporter: John Ament > > Currently, you cannot have a nonbinding producer method, e.g. one where the annotation is read at runtime, with a scope. This means that repeated injections always happen. It would be better if you could scope the nonbinding producer methods, so that the results were bound, e.g. to a request scope, so that look ups can be done once. > The current way to avoid this is to use a holder object with the proper scope. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:08:06 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 11:08:06 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-467) Java 8 Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-467: ------------------------------------- Epic Name: CDI 2.0 JSE8 > Java 8 Epic for CDI 2.0 > ----------------------- > > Key: CDI-467 > URL: https://issues.jboss.org/browse/CDI-467 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all work and documents about possible in CDI 2.0 due to Java SE 8.0 > Draft document is here : https://docs.google.com/document/d/1KUaxXIXJ_r-h5UJGIij6I4vrLS7uXkeeeZr2SaRipWQ/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:09:04 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 11:09:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-466) Contexts Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-466: ------------------------------------- Epic Name: CDI 2.0 Contexts > Contexts Epic for CDI 2.0 > ------------------------- > > Key: CDI-466 > URL: https://issues.jboss.org/browse/CDI-466 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all work and documents about possible contexts enhancement in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1tIFNoe9sdyvXT1wTjIeT7ARDaoRZR0IWzcfvKrmdIX4/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:09:05 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 11:09:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-465) SPI Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-465: ------------------------------------- Epic Name: CDI 2 SPI > SPI Epic for CDI 2.0 > -------------------- > > Key: CDI-465 > URL: https://issues.jboss.org/browse/CDI-465 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all work and documents about possible SPI enhancement in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1aK3aIQG-W9D72Ti9fj0xLFNmqxQtYyy_vjc6QgN3Z2Y/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:10:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 11:10:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-467) Java 8 Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-467: ------------------------------------- Epic Name: CDI 2 JSE8 (was: CDI 2.0 JSE8) > Java 8 Epic for CDI 2.0 > ----------------------- > > Key: CDI-467 > URL: https://issues.jboss.org/browse/CDI-467 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all work and documents about possible in CDI 2.0 due to Java SE 8.0 > Draft document is here : https://docs.google.com/document/d/1KUaxXIXJ_r-h5UJGIij6I4vrLS7uXkeeeZr2SaRipWQ/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:10:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 11:10:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-466) Contexts Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-466: ------------------------------------- Epic Name: CDI 2 Contexts (was: CDI 2.0 Contexts) > Contexts Epic for CDI 2.0 > ------------------------- > > Key: CDI-466 > URL: https://issues.jboss.org/browse/CDI-466 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all work and documents about possible contexts enhancement in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1tIFNoe9sdyvXT1wTjIeT7ARDaoRZR0IWzcfvKrmdIX4/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:10:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 11:10:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-467) Java 8 Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-467: ------------------------------------- Epic Name: CDI 2 JDK8 (was: CDI 2 JSE8) > Java 8 Epic for CDI 2.0 > ----------------------- > > Key: CDI-467 > URL: https://issues.jboss.org/browse/CDI-467 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all work and documents about possible in CDI 2.0 due to Java SE 8.0 > Draft document is here : https://docs.google.com/document/d/1KUaxXIXJ_r-h5UJGIij6I4vrLS7uXkeeeZr2SaRipWQ/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:11:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 11:11:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-464) Java SE Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-464: ------------------------------------- Epic Name: CDI 2 JSE > Java SE Epic for CDI 2.0 > ------------------------ > > Key: CDI-464 > URL: https://issues.jboss.org/browse/CDI-464 > Project: CDI Specification Issues > Issue Type: Epic > Components: Java SE Integration > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all work and documents about Java SE bootstrap in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:11:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 11:11:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-463) Events Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-463: ------------------------------------- Epic Name: CDI 2 Events > Events Epic for CDI 2.0 > ----------------------- > > Key: CDI-463 > URL: https://issues.jboss.org/browse/CDI-463 > Project: CDI Specification Issues > Issue Type: Epic > Components: Events > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all work and documents about possible events enhancement in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1lFtgLm6hY-uECdA1r0Sfimq6vkVYThoUZsevPUaSP0E/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:11:03 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 11:11:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-462) Parts Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-462: ------------------------------------- Epic Name: CDI 2 Parts > Parts Epic for CDI 2.0 > ---------------------- > > Key: CDI-462 > URL: https://issues.jboss.org/browse/CDI-462 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > this Epic ticket gathers all tickets and work documents about the introudction of parts (modularity) in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1AEBjQl00CZ9ERfgXSHq9cdxrngwsERjUCEmcdzgMSZ4/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:12:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 11:12:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-461) Configuration Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-461: ------------------------------------- Epic Name: CDI 2 Config > Configuration Epic for CDI 2.0 > ------------------------------ > > Key: CDI-461 > URL: https://issues.jboss.org/browse/CDI-461 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all tickets and work document about studying the possible introduction of configuration feature in CDI 2.0. > Draft document is here : https://docs.google.com/document/d/1378aTRNgCMXRYP9LBYRuGdan0mmQ3rPjjIYLWv2AB9I/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:13:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 11:13:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-478) Interceptor and Decorator EPIC for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-478: ------------------------------------- Epic Name: CDI 2 AOP (was: Interceptor and Decorator EPIC for CDI 2.0) > Interceptor and Decorator EPIC for CDI 2.0 > ------------------------------------------ > > Key: CDI-478 > URL: https://issues.jboss.org/browse/CDI-478 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > > This Epic ticket gathers all work and documents about interceptor and decorator in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/10iexiDfMT9tYaUPa2cGiw4P68VG_bryDIS0DKzP1ils/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:13:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 11:13:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-478) Interceptor and Decorator EPIC for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-478: ------------------------------------- Fix Version/s: 2.0 (discussion) > Interceptor and Decorator EPIC for CDI 2.0 > ------------------------------------------ > > Key: CDI-478 > URL: https://issues.jboss.org/browse/CDI-478 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all work and documents about interceptor and decorator in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/10iexiDfMT9tYaUPa2cGiw4P68VG_bryDIS0DKzP1ils/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:14:04 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Mon, 15 Sep 2014 11:14:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-469) Allow nonbinding producer methods to have scopes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002464#comment-13002464 ] Jozef Hartinger commented on CDI-469: ------------------------------------- My understanding of the usecase is the following: Suppose we have a *binding* qualifier: {code:JAVA} @Qualifier ... public @interface Converter { String value(); } {code} and we want to produce several distinct beans e.g.: @ApplicationScoped @Converter("foo") Function @ApplicationScoped @Converter("bar") Function We have to write a separate producer method for each, specifying the binding qualifier. We cannot write one producer to produce both foo and bar. We do not however want to duplicate the producer method code. Instead, we would like to direct creation to the single generic method that, should it know the value of @Converter annotation, is capable of creating the bean instance. Something like binding at the injection point side but non-binding at the producer side. > Allow nonbinding producer methods to have scopes > ------------------------------------------------ > > Key: CDI-469 > URL: https://issues.jboss.org/browse/CDI-469 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Contexts > Affects Versions: 1.2.Final > Reporter: John Ament > > Currently, you cannot have a nonbinding producer method, e.g. one where the annotation is read at runtime, with a scope. This means that repeated injections always happen. It would be better if you could scope the nonbinding producer methods, so that the results were bound, e.g. to a request scope, so that look ups can be done once. > The current way to avoid this is to use a holder object with the proper scope. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:14:04 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 11:14:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-279) Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-279: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-279 > URL: https://issues.jboss.org/browse/CDI-279 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Hong Zhang > Assignee: Pete Muir > Fix For: 2.0 (discussion) > > > Please provide CDI SPI that could be used to directly replace the java.lang.reflect methods when expanding the use of @Stereotype to Java EE 7 platform. > Also attaching the relevant sections from Bill's @Stereotype proposal below: > ================================================ > Stereotypes are implemented by CDI, but (typically) the Java EE deployment processing has no knowledge of CDI when it's looking for Java EE annotations. Integrating with CDI so that stereotypes could be considered during this deployment-time annotation processing would require a new CDI SPI. > Many existing implementations would need to be changed to understand > how to expand stereotypes. Requiring every technology to do this > itself will almost certainly lead to inconsistencies. Since stereotypes > are a CDI feature, CDI will provide a simple replacement for the > java.lang.reflect methods such as getAnnotations that takes into > account stereotypes. > Some technologies will not want to have a hard dependency on CDI so > we'll need to provide a simple way for them to conditionally invoke > these new methods only if CDI is present, falling back to java.lang.reflect > if not. This seems straightforward. In this case, the functionality of > @Stereotype would not be available to applications that chose to run > without CDI. > =============================== -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:30:03 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Mon, 15 Sep 2014 11:30:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-469) Allow nonbinding producer methods to have scopes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002474#comment-13002474 ] Antonin Stefanutti commented on CDI-469: ---------------------------------------- [~jharting], indeed, I think that's the general idea. Otherwise stated, the need is to be able to have non {{@Dependent}} producer methods depending on the {{InjectPoint}} and somehow have the resultant produced values _cached_ (i.e. the producer method does not get called twice without the active scope) whenever the {{InjectionPoint}} are _equals_, _equals_ being here defined by qualifiers equality. > Allow nonbinding producer methods to have scopes > ------------------------------------------------ > > Key: CDI-469 > URL: https://issues.jboss.org/browse/CDI-469 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Contexts > Affects Versions: 1.2.Final > Reporter: John Ament > > Currently, you cannot have a nonbinding producer method, e.g. one where the annotation is read at runtime, with a scope. This means that repeated injections always happen. It would be better if you could scope the nonbinding producer methods, so that the results were bound, e.g. to a request scope, so that look ups can be done once. > The current way to avoid this is to use a holder object with the proper scope. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 12:29:04 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 15 Sep 2014 12:29:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-47) Add required attribute to tag in beans.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-47. ------------------------------------- Fix Version/s: 1.1.Final (was: TBD) Resolution: Done This feature was resolve with CDI 1.1 and the introduction of {{@Priority}} for interceptor. > Add required attribute to tag in beans.xml > --------------------------------------------------------- > > Key: CDI-47 > URL: https://issues.jboss.org/browse/CDI-47 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 1.1.Final > > > Currently the deployment will fail if an interceptor is not present, which means that it is not conventient to use interceptors from optional modules, as the end user will need to open up the jar file and edit the beans.xml file manually. > Adding a required="true|false" attribute to the element in beans.xml would allow an archive to specify that the interceptor is not essential, and if it is not found it should simply be ignored. > For example, currently Seam Security has a hard dependency on Seam Persistence because it uses the Transaction interceptor, and the deployment will fail if Seam Persistence is not present. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 04:36:02 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 16 Sep 2014 04:36:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-479) How to identify the bean a static observer method belongs to In-Reply-To: References: Message-ID: Martin Kouba created CDI-479: -------------------------------- Summary: How to identify the bean a static observer method belongs to Key: CDI-479 URL: https://issues.jboss.org/browse/CDI-479 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba Let's sum up some parts of the spec which are relevant to static observer methods: "10.4. Observer methods": {quote} An observer method is a non-abstract method of a managed bean class or session bean class... An observer method may be either static or non-static. {quote} "10.3. Observer resolution": {quote} An event is delivered to an observer method if: * The observer method belongs to an enabled bean. * ... {quote} "12.4.3. Bean discovery": {quote} For each observer method of every enabled bean, the container registers an instance of the ObserverMethod interface defined in The ObserverMethod interface. {quote} Now what is the algorithm to *identify the bean a static observer method belongs to*? Is is bound to all beans whose Bean.getBeanClass() declares the method? There are two special scenarios I have in mind: h3. Static observer method on an abstract class {code:java} public abstract class Foo { public static observe1(@Observes Event1 event1) { } } public class Bar extends Foo { } {code} Foo is not a bean. Foo.observe1() is not a method of managed bean class Bar (if we strictly follow the JSL). Is the observer method detected? Does it belong to Bar? What if there are several subclasses of Foo? h3. Specialization {code:java} public class Foo { public static observe1(@Observes Event2 event2) { } } @Specializes public class Bar extends Foo { } {code} Foo is specialized by Bar and thus it's disabled. Is the observer method detected? Does it belong to Bar? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 08:35:02 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 16 Sep 2014 08:35:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-468) Extend javax.interceptor.InvocationContext In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002820#comment-13002820 ] Martin Kouba commented on CDI-468: ---------------------------------- Looks like a good idea. We should probably expose the set of all method/constructor interceptor bindings: {code} Collection getInterceptorBindings(); {code} And this set could be empty if there are no bindings declared and only interceptors using the {{@Interceptors}} annotation are associated. Anyway, if we conclude that this is useful and doable we should file a new interceptor spec issue. > Extend javax.interceptor.InvocationContext > ------------------------------------------ > > Key: CDI-468 > URL: https://issues.jboss.org/browse/CDI-468 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Arne Limburg > > Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly. > I propose to extend the javax.interceptor.InvocationContext interface with a method > public Annotation getInterceptorBinding() or > public A getInterceptorBinding(Class type) > The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 08:52:03 2014 From: issues at jboss.org (Arne Limburg (JIRA)) Date: Tue, 16 Sep 2014 08:52:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-468) Extend javax.interceptor.InvocationContext In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002834#comment-13002834 ] Arne Limburg commented on CDI-468: ---------------------------------- I thought about filing an interceptor spec issue, too. But the interceptor spec does not care about interceptor bindings at all. Anyway it would be way better, if such method would be located directly in the InvocationContext (and not in a sub-interface). > Extend javax.interceptor.InvocationContext > ------------------------------------------ > > Key: CDI-468 > URL: https://issues.jboss.org/browse/CDI-468 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Arne Limburg > > Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly. > I propose to extend the javax.interceptor.InvocationContext interface with a method > public Annotation getInterceptorBinding() or > public A getInterceptorBinding(Class type) > The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 08:57:05 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 16 Sep 2014 08:57:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-468) Extend javax.interceptor.InvocationContext In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002840#comment-13002840 ] Martin Kouba commented on CDI-468: ---------------------------------- [~arnelim] Well, it does care, since v1.2 (Java EE 7), see also Chapter 3, "Associating Interceptors using Interceptor Bindings". {quote} Anyway it would be way better, if such method would be located directly in the InvocationContext (and not in a sub-interface) {quote} Agreed. > Extend javax.interceptor.InvocationContext > ------------------------------------------ > > Key: CDI-468 > URL: https://issues.jboss.org/browse/CDI-468 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Arne Limburg > > Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly. > I propose to extend the javax.interceptor.InvocationContext interface with a method > public Annotation getInterceptorBinding() or > public A getInterceptorBinding(Class type) > The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 09:36:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 16 Sep 2014 09:36:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-54) Abstract Producer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002875#comment-13002875 ] Antoine Sabot-Durand commented on CDI-54: ----------------------------------------- [~pmuir] do you know how to recover the original request on seam website ? > Abstract Producer methods > ------------------------- > > Key: CDI-54 > URL: https://issues.jboss.org/browse/CDI-54 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 09:55:02 2014 From: issues at jboss.org (Pete Muir (JIRA)) Date: Tue, 16 Sep 2014 09:55:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-54) Abstract Producer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002895#comment-13002895 ] Pete Muir commented on CDI-54: ------------------------------ [~mkouba] is working on this. > Abstract Producer methods > ------------------------- > > Key: CDI-54 > URL: https://issues.jboss.org/browse/CDI-54 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 10:15:16 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 16 Sep 2014 10:15:16 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-61) Producers and beans that are under construction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-61: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > Producers and beans that are under construction > ----------------------------------------------- > > Key: CDI-61 > URL: https://issues.jboss.org/browse/CDI-61 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > > I think we need the spec to say something about cases where an injection point of a bean resolves to a producer method of the same bean. The implementation should detect that this is a definition error. It shouldn't try to call a producer method on a non-fully-initialized bean. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 10:22:03 2014 From: issues at jboss.org (Arne Limburg (JIRA)) Date: Tue, 16 Sep 2014 10:22:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-469) Allow nonbinding producer methods to have scopes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002911#comment-13002911 ] Arne Limburg commented on CDI-469: ---------------------------------- Hmm, sounds like the attribute of the qualifier should not be @Nonbinding, but something new like @MultipleInstanceBinding or something like that > Allow nonbinding producer methods to have scopes > ------------------------------------------------ > > Key: CDI-469 > URL: https://issues.jboss.org/browse/CDI-469 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Contexts > Affects Versions: 1.2.Final > Reporter: John Ament > > Currently, you cannot have a nonbinding producer method, e.g. one where the annotation is read at runtime, with a scope. This means that repeated injections always happen. It would be better if you could scope the nonbinding producer methods, so that the results were bound, e.g. to a request scope, so that look ups can be done once. > The current way to avoid this is to use a holder object with the proper scope. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 11:10:03 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 16 Sep 2014 11:10:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-61) Producers and beans that are under construction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002968#comment-13002968 ] Antoine Sabot-Durand commented on CDI-61: ----------------------------------------- The only rule for this use case in the spec regarding circularities (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#injection_el_resolution) {quote} The container is required to support circularities in the bean dependency graph where at least one bean participating in every circular chain of dependencies has a normal scope, as defined in Normal scopes and pseudo-scopes. The container is not required to support circular chains of dependencies where every bean participating in the chain has a pseudo-scope. {quote} Weld 2.1.x support this use c > Producers and beans that are under construction > ----------------------------------------------- > > Key: CDI-61 > URL: https://issues.jboss.org/browse/CDI-61 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > > I think we need the spec to say something about cases where an injection point of a bean resolves to a producer method of the same bean. The implementation should detect that this is a definition error. It shouldn't try to call a producer method on a non-fully-initialized bean. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 11:13:05 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 16 Sep 2014 11:13:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-61) Producers and beans that are under construction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002968#comment-13002968 ] Antoine Sabot-Durand edited comment on CDI-61 at 9/16/14 11:12 AM: ------------------------------------------------------------------- The only rule for this use case in the spec regarding circularities (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#injection_el_resolution) {quote} The container is required to support circularities in the bean dependency graph where at least one bean participating in every circular chain of dependencies has a normal scope, as defined in Normal scopes and pseudo-scopes. The container is not required to support circular chains of dependencies where every bean participating in the chain has a pseudo-scope. {quote} And yet it's not exactly this use case. Weld 2.1.x support this use case with a warning while OWB 1.2.6 crash with a stack overflow. Is there any objection to be explicit and tell that the container doesn't have to support this kind of circularities? was (Author: antoinesabot-durand): The only rule for this use case in the spec regarding circularities (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#injection_el_resolution) {quote} The container is required to support circularities in the bean dependency graph where at least one bean participating in every circular chain of dependencies has a normal scope, as defined in Normal scopes and pseudo-scopes. The container is not required to support circular chains of dependencies where every bean participating in the chain has a pseudo-scope. {quote} Weld 2.1.x support this use c > Producers and beans that are under construction > ----------------------------------------------- > > Key: CDI-61 > URL: https://issues.jboss.org/browse/CDI-61 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > > I think we need the spec to say something about cases where an injection point of a bean resolves to a producer method of the same bean. The implementation should detect that this is a definition error. It shouldn't try to call a producer method on a non-fully-initialized bean. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 11:15:05 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 16 Sep 2014 11:15:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-63) Add section on cyclic dependencies to the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-63: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > Add section on cyclic dependencies to the spec > ---------------------------------------------- > > Key: CDI-63 > URL: https://issues.jboss.org/browse/CDI-63 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 11:46:03 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 16 Sep 2014 11:46:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-79) Allow you to inspect the decorator chain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-79: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > Allow you to inspect the decorator chain > ---------------------------------------- > > Key: CDI-79 > URL: https://issues.jboss.org/browse/CDI-79 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 11:51:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 16 Sep 2014 11:51:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-89) Add @Unwraps from Seam Solder In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-89: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > Add @Unwraps from Seam Solder > ------------------------------ > > Key: CDI-89 > URL: https://issues.jboss.org/browse/CDI-89 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: 2.0 (discussion) > > > @Unwraps allows for an essentially stateless scope for producer methods and fields. > At injection time a dependent scoped proxy is injected into the injection point. When a methods is invoked on this proxy it calls the corresponding @Unwraps methods to get the instance to invoke the method on. > Because the proxy is @Dependent scoped, the @Unwraps method can inject the corresponding InjectionPoint. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 11:56:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 16 Sep 2014 11:56:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-103) Support client controlled contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-103: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Support client controlled contexts > ---------------------------------- > > Key: CDI-103 > URL: https://issues.jboss.org/browse/CDI-103 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > > In a client controlled context, the client controls via some identifier (probably an identifier, but we should allow the context to inspect the injection point) which contextual instances it sees for a particular bean type. For example given: > {code} > @MyScope > class Foo { > String name; > } > {code} > and a context which uses annotations to differentiate between contextual instance, these two injection points would see different instances: > {code} > @Inject @Bar Foo barFoo; > @Inject @Baz Foo bazFoo; > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 12:41:03 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 16 Sep 2014 12:41:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-104) Support automatic dependency injection for non-managed objects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003027#comment-13003027 ] Antoine Sabot-Durand commented on CDI-104: ------------------------------------------ Yes [~stefanutti], but in a less automatic way ;). > Support automatic dependency injection for non-managed objects > -------------------------------------------------------------- > > Key: CDI-104 > URL: https://issues.jboss.org/browse/CDI-104 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Dan Allen > Fix For: 1.1.Final > > > Allow objects created using the "new" keyword (or created by some other means) to be injected automatically. > Conceptually it would look something like this: > @AutoInject > public class AccountService { > private final Account account; > @Inject > private PaymentProcessor paymentProcessor; > AccountService(Account account) { > this.account = account; > } > public void doPayment(double amount) { > paymentProcessor.processPayment(account, amount); > } > } > We could then create the object using new and the fields will still be injected: > AccountService a = new AccountService(account); > a.doPayment(10); > The inverse design would also be an option. An instance of Account could be retrieved from JPA and the AccountService would be injected into it during construction. > To implement this feature may require a javaagent, which will modify the bytecode of @AutoInject annotated classes as they are loaded, so that the constructor bytecode looks up the values to inject and sets the injected field values appropriately. (There are other options suggested in the linked thread). > The primary use case for this feature is to support rich domain models, though the usefulness of this feature extends beyond this case, so I don't think the feature should be dismissed if you don't agree with the rich domain models design. > The feature also brings the "new" keyword back into the picture of modern programming. You can still create objects in the classic way, but benefit from modern programming model patterns (specifically CDI). > Spring has a similar feature in it's AOP package: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/aop.html#aop-atconfigurable -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 12:41:05 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 16 Sep 2014 12:41:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-104) Support automatic dependency injection for non-managed objects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-104. -------------------------------------- Fix Version/s: 1.1.Final (was: TBD) Resolution: Done > Support automatic dependency injection for non-managed objects > -------------------------------------------------------------- > > Key: CDI-104 > URL: https://issues.jboss.org/browse/CDI-104 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Dan Allen > Fix For: 1.1.Final > > > Allow objects created using the "new" keyword (or created by some other means) to be injected automatically. > Conceptually it would look something like this: > @AutoInject > public class AccountService { > private final Account account; > @Inject > private PaymentProcessor paymentProcessor; > AccountService(Account account) { > this.account = account; > } > public void doPayment(double amount) { > paymentProcessor.processPayment(account, amount); > } > } > We could then create the object using new and the fields will still be injected: > AccountService a = new AccountService(account); > a.doPayment(10); > The inverse design would also be an option. An instance of Account could be retrieved from JPA and the AccountService would be injected into it during construction. > To implement this feature may require a javaagent, which will modify the bytecode of @AutoInject annotated classes as they are loaded, so that the constructor bytecode looks up the values to inject and sets the injected field values appropriately. (There are other options suggested in the linked thread). > The primary use case for this feature is to support rich domain models, though the usefulness of this feature extends beyond this case, so I don't think the feature should be dismissed if you don't agree with the rich domain models design. > The feature also brings the "new" keyword back into the picture of modern programming. You can still create objects in the classic way, but benefit from modern programming model patterns (specifically CDI). > Spring has a similar feature in it's AOP package: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/aop.html#aop-atconfigurable -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 12:43:03 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 16 Sep 2014 12:43:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-108) Align with release of @Inject included in the Java EE 7 platform In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-108. -------------------------------------- Fix Version/s: (was: TBD) Resolution: Out of Date Java EE 7 is closed and included no AtInject update > Align with release of @Inject included in the Java EE 7 platform > ---------------------------------------------------------------- > > Key: CDI-108 > URL: https://issues.jboss.org/browse/CDI-108 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Java EE integration > Reporter: Pete Muir > > There is likely to be an update to JSR-330, @Inject, which we should align with. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 07:17:02 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 17 Sep 2014 07:17:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003402#comment-13003402 ] Martin Kouba commented on CDI-458: ---------------------------------- Looks like a good idea. However, we should also clarify that POM is not fired for container lifecycle events. Although it makes sense it's not explicitly stated anywhere. Furthermore, it's not clear whether POM is fired for *non-container lifecycle events* declared on an extension (AFAIK Weld does not fire POM, nor PIP, for these). Note that "11.5. Container lifecycle events": {quote} Service providers may have observer methods, which *may observe any event*, including any container lifecycle event, and obtain an injected BeanManager reference... {quote} and "12.4.3. Bean discovery": {quote} For each enabled bean, the container must search the class for observer methods, and for each observer method: * ... * fire an event of type ProcessObserverMethod, as defined in ProcessObserverMethod event. {quote} > Give the possibility to deactivate an observer in ProcessObserverMethod > ----------------------------------------------------------------------- > > Key: CDI-458 > URL: https://issues.jboss.org/browse/CDI-458 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > Today if a user want to deactivate an observer at deployment time, she needs to observes {{ProcessAnnotatedType}} with {{@WithAnnotation(Observes.class)}} and replace the annotatedType by a new one without the {{@Observes}} annotation. It's quite heavy to manage. > We could add a {{veto()}} method in {{ProcessObserverMethod}} to do this in a far easier and intuitive way. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 08:03:03 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 17 Sep 2014 08:03:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003430#comment-13003430 ] Martin Kouba commented on CDI-45: --------------------------------- I don't really see any benefit from introducing any additional interface, aside from performance. And some performance issues may be partially solved by implementation. +1 for introducing a new convenient method {{Instance.isResolved()}} (or any other better name). > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antoine at sabot-durand.net Wed Sep 17 08:19:31 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 17 Sep 2014 14:19:31 +0200 Subject: [cdi-dev] Today's meeting Message-ID: <48C45E63-2510-43F2-9CF7-EA5D85E3E986@sabot-durand.net> Hi all, Just realised I didn?t post my proposed agenda of today?s meeting. Here are the point I want to deal with : - Back on AtInject proposal doc There have been some good comment ont he doc regarding @Deafault and @Any, we should discuss that IMO. For those who missed it the doc is here : https://docs.google.com/document/d/1KCzqodA8uzXED5DJrEUyl0x3dOUB5mBwL4KcV8xUY_w/edit?usp=sharing - Discuss the workshop organisation : who wants to lead what - Other organisation question Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140917/3fbe02f8/attachment.html From issues at jboss.org Wed Sep 17 10:25:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 17 Sep 2014 10:25:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-480) Introduce real link between spec doc and TCK In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-480: ---------------------------------------- Summary: Introduce real link between spec doc and TCK Key: CDI-480 URL: https://issues.jboss.org/browse/CDI-480 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.1.Final Reporter: Antoine Sabot-Durand One of the nicest thing in CDI TCK is the audit files. These XML files (like : https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/resources/tck-audit-cdi.xml) list all challenges coming from the specification and allow to bind a given test to a given challenge thanks to {{@SpecAssertion}} annotation (see https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/definition/name/NameDefinitionTest.java#L54-L55 for instance). This system is great to know what assertions are broken, retrieve what spec rule is tested from the code and have nice report on spec coverage in TCK. The only weakness here is that these audit files are only maintained "by hand" when we could (perhaps) have an automatic or semi-automatic way of generating or at least checking these file against the spec. This could be done by creating an Asciidoc macro or extension (not sure of the terminology) and add a meta data set to each rule written in the spec (allowing to have one or more test for one rule). These meta could be used to help generate the xml file for the TCK or at least check that they contains all rules from the spec. The immediate benefit I see here would be : # make the spec contributors more concerned about TCK # reduce the risk of forgetting rules in TCK # produce a version of the spec with links to TCK test # reduce the fear of refactoring the spec if needed To make short, if this "unification" could be done, it would probably give us more efficiency and improve spec and TCK quality. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 10:32:02 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 17 Sep 2014 10:32:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-480) Introduce real link between spec doc and TCK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-480: ------------------------------------- Description: One of the nicest thing in CDI TCK is the audit files. These XML files (like : https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/resources/tck-audit-cdi.xml) list all challenges coming from the specification and allow to bind a given test to a given challenge thanks to {{@SpecAssertion}} annotation (see https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/definition/name/NameDefinitionTest.java#L54-L55 for instance). This system is great to know what assertions are broken, retrieve what spec rule is tested from the code and have nice report on spec coverage in TCK. The only weakness here is that these audit files are only maintained "by hand" when we could (perhaps) have an automatic or semi-automatic way of generating them or at least checking them against the spec. Since the spec doc is generated with Asciidoctor, this could be done by creating an Asciidoctor macro or extension (not sure of the terminology) and add a meta data set to each rule written in the spec (allowing to have one or more test for one rule). These meta could be used to help generate the xml file for the TCK or at least check that they contains all rules from the spec. The immediate benefit I see here would be : # make the spec contributors more concerned about TCK # reduce the risk of forgetting rules in TCK # produce a version of the spec with links to TCK test # reduce the fear of refactoring the spec if needed To make short, if this "unification" could be done, it would probably give us more efficiency and improve spec and TCK quality. was: One of the nicest thing in CDI TCK is the audit files. These XML files (like : https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/resources/tck-audit-cdi.xml) list all challenges coming from the specification and allow to bind a given test to a given challenge thanks to {{@SpecAssertion}} annotation (see https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/definition/name/NameDefinitionTest.java#L54-L55 for instance). This system is great to know what assertions are broken, retrieve what spec rule is tested from the code and have nice report on spec coverage in TCK. The only weakness here is that these audit files are only maintained "by hand" when we could (perhaps) have an automatic or semi-automatic way of generating or at least checking these file against the spec. This could be done by creating an Asciidoc macro or extension (not sure of the terminology) and add a meta data set to each rule written in the spec (allowing to have one or more test for one rule). These meta could be used to help generate the xml file for the TCK or at least check that they contains all rules from the spec. The immediate benefit I see here would be : # make the spec contributors more concerned about TCK # reduce the risk of forgetting rules in TCK # produce a version of the spec with links to TCK test # reduce the fear of refactoring the spec if needed To make short, if this "unification" could be done, it would probably give us more efficiency and improve spec and TCK quality. > Introduce real link between spec doc and TCK > -------------------------------------------- > > Key: CDI-480 > URL: https://issues.jboss.org/browse/CDI-480 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.1.Final > Reporter: Antoine Sabot-Durand > > One of the nicest thing in CDI TCK is the audit files. These XML files (like : https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/resources/tck-audit-cdi.xml) list all challenges coming from the specification and allow to bind a given test to a given challenge thanks to {{@SpecAssertion}} annotation (see https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/definition/name/NameDefinitionTest.java#L54-L55 for instance). > This system is great to know what assertions are broken, retrieve what spec rule is tested from the code and have nice report on spec coverage in TCK. > The only weakness here is that these audit files are only maintained "by hand" when we could (perhaps) have an automatic or semi-automatic way of generating them or at least checking them against the spec. > Since the spec doc is generated with Asciidoctor, this could be done by creating an Asciidoctor macro or extension (not sure of the terminology) and add a meta data set to each rule written in the spec (allowing to have one or more test for one rule). These meta could be used to help generate the xml file for the TCK or at least check that they contains all rules from the spec. > The immediate benefit I see here would be : > # make the spec contributors more concerned about TCK > # reduce the risk of forgetting rules in TCK > # produce a version of the spec with links to TCK test > # reduce the fear of refactoring the spec if needed > > To make short, if this "unification" could be done, it would probably give us more efficiency and improve spec and TCK quality. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From mpaluch at paluch.biz Thu Sep 18 03:20:58 2014 From: mpaluch at paluch.biz (Mark Paluch) Date: Thu, 18 Sep 2014 09:20:58 +0200 Subject: [cdi-dev] Handling of Google Docs document suggestions Message-ID: Hi Antoine, all edits in the shared Google Docs are done in suggest mode. Do you have a plan how to achieve an initial document forming the discussion base? Who is in charge of moderating the documents, accepting/declining suggestions? Thanks and best regards, Mark -- Mark Paluch -- PALUCH.biz Heckenpfad 14 // 69469 Weinheim T. 0 62 01/65 04 24-0 // F. 0 62 01/65 04 24-9 mpaluch at paluch.biz WWW. http://www.paluch.biz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140918/9c40a030/attachment.html From issues at jboss.org Thu Sep 18 11:40:02 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 18 Sep 2014 11:40:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-481) Introduce AnnotatedParameter.getJavaParameter() In-Reply-To: References: Message-ID: Jozef Hartinger created CDI-481: ----------------------------------- Summary: Introduce AnnotatedParameter.getJavaParameter() Key: CDI-481 URL: https://issues.jboss.org/browse/CDI-481 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Reporter: Jozef Hartinger Make it possible to obtain the Java Reflection object representing the parameter. This is in line with AnnotatedField.getJavaMember() AnnotatedMethod.getJavaMember() AnnotatedConstructor.getJavaMember() Can be implemented as a default method such as: {code:JAVA} default Parameter getJavaParameter() { Member member = getDeclaringCallable().getJavaMember(); if (!(member instanceof Executable)) { throw new IllegalStateException("Parameter does not belong to an executable " + member); } Executable executable = (Executable) member; return executable.getParameters()[getPosition()]; } {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 11:45:03 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 18 Sep 2014 11:45:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-481) Introduce AnnotatedParameter.getJavaParameter() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003996#comment-13003996 ] Romain Manni-Bucau commented on CDI-481: ---------------------------------------- Can be interesting to align it on BVal with parameter naming, no? > Introduce AnnotatedParameter.getJavaParameter() > ----------------------------------------------- > > Key: CDI-481 > URL: https://issues.jboss.org/browse/CDI-481 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Jozef Hartinger > > Make it possible to obtain the Java Reflection object representing the parameter. This is in line with > AnnotatedField.getJavaMember() > AnnotatedMethod.getJavaMember() > AnnotatedConstructor.getJavaMember() > Can be implemented as a default method such as: > {code:JAVA} > default Parameter getJavaParameter() { > Member member = getDeclaringCallable().getJavaMember(); > if (!(member instanceof Executable)) { > throw new IllegalStateException("Parameter does not belong to an executable " + member); > } > Executable executable = (Executable) member; > return executable.getParameters()[getPosition()]; > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 11:50:02 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 18 Sep 2014 11:50:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-481) Introduce AnnotatedParameter.getJavaParameter() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003998#comment-13003998 ] Jozef Hartinger commented on CDI-481: ------------------------------------- {quote}Can be interesting to align it on BVal with parameter naming, no?{quote} Sorry, I don't follow. Please elaborate. > Introduce AnnotatedParameter.getJavaParameter() > ----------------------------------------------- > > Key: CDI-481 > URL: https://issues.jboss.org/browse/CDI-481 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Jozef Hartinger > > Make it possible to obtain the Java Reflection object representing the parameter. This is in line with > AnnotatedField.getJavaMember() > AnnotatedMethod.getJavaMember() > AnnotatedConstructor.getJavaMember() > Can be implemented as a default method such as: > {code:JAVA} > default Parameter getJavaParameter() { > Member member = getDeclaringCallable().getJavaMember(); > if (!(member instanceof Executable)) { > throw new IllegalStateException("Parameter does not belong to an executable " + member); > } > Executable executable = (Executable) member; > return executable.getParameters()[getPosition()]; > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 12:01:03 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 18 Sep 2014 12:01:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-481) Introduce AnnotatedParameter.getJavaParameter() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004003#comment-13004003 ] Romain Manni-Bucau commented on CDI-481: ---------------------------------------- http://javadox.com/javax/javaee-api/7.0/javax/validation/ParameterNameProvider.html this way extensions can use parameters name which can be useful for extension configuration and match it with something better/more expressive than index. > Introduce AnnotatedParameter.getJavaParameter() > ----------------------------------------------- > > Key: CDI-481 > URL: https://issues.jboss.org/browse/CDI-481 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Jozef Hartinger > > Make it possible to obtain the Java Reflection object representing the parameter. This is in line with > AnnotatedField.getJavaMember() > AnnotatedMethod.getJavaMember() > AnnotatedConstructor.getJavaMember() > Can be implemented as a default method such as: > {code:JAVA} > default Parameter getJavaParameter() { > Member member = getDeclaringCallable().getJavaMember(); > if (!(member instanceof Executable)) { > throw new IllegalStateException("Parameter does not belong to an executable " + member); > } > Executable executable = (Executable) member; > return executable.getParameters()[getPosition()]; > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 12:49:03 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 18 Sep 2014 12:49:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-481) Introduce AnnotatedParameter.getJavaParameter() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004021#comment-13004021 ] Jozef Hartinger commented on CDI-481: ------------------------------------- Oh, I see. The named would be available here as AnnotatedParameter.getJavaParameter().getName() > Introduce AnnotatedParameter.getJavaParameter() > ----------------------------------------------- > > Key: CDI-481 > URL: https://issues.jboss.org/browse/CDI-481 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Jozef Hartinger > > Make it possible to obtain the Java Reflection object representing the parameter. This is in line with > AnnotatedField.getJavaMember() > AnnotatedMethod.getJavaMember() > AnnotatedConstructor.getJavaMember() > Can be implemented as a default method such as: > {code:JAVA} > default Parameter getJavaParameter() { > Member member = getDeclaringCallable().getJavaMember(); > if (!(member instanceof Executable)) { > throw new IllegalStateException("Parameter does not belong to an executable " + member); > } > Executable executable = (Executable) member; > return executable.getParameters()[getPosition()]; > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 13:54:02 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 18 Sep 2014 13:54:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-481) Introduce AnnotatedParameter.getJavaParameter() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004040#comment-13004040 ] Romain Manni-Bucau commented on CDI-481: ---------------------------------------- Yep. If you think to an extension allowing kind of dynamic calls it can use then names instead of index or type (which are not enough). For instance: {code} @PreSecurity("authenticator.login(username, password) public Data getSensitiveData() { // ... } // ... @Named public class Authenticator { public boolean login(String user, String pwd) { return true; } } {code} > Introduce AnnotatedParameter.getJavaParameter() > ----------------------------------------------- > > Key: CDI-481 > URL: https://issues.jboss.org/browse/CDI-481 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Jozef Hartinger > > Make it possible to obtain the Java Reflection object representing the parameter. This is in line with > AnnotatedField.getJavaMember() > AnnotatedMethod.getJavaMember() > AnnotatedConstructor.getJavaMember() > Can be implemented as a default method such as: > {code:JAVA} > default Parameter getJavaParameter() { > Member member = getDeclaringCallable().getJavaMember(); > if (!(member instanceof Executable)) { > throw new IllegalStateException("Parameter does not belong to an executable " + member); > } > Executable executable = (Executable) member; > return executable.getParameters()[getPosition()]; > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 13:54:02 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 18 Sep 2014 13:54:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-481) Introduce AnnotatedParameter.getJavaParameter() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004040#comment-13004040 ] Romain Manni-Bucau edited comment on CDI-481 at 9/18/14 1:53 PM: ----------------------------------------------------------------- Yep. If you think to an extension allowing kind of dynamic calls it can use then names instead of index or type (which are not enough). For instance: {code} @PreSecurity("authenticator.login(username, password) public Data getSensitiveData() { // ... } // ... @Named public class Authenticator { public boolean login(@Parameter("username") String user, @Parameter("password") String pwd) { return true; } } {code} was (Author: rmannibucau): Yep. If you think to an extension allowing kind of dynamic calls it can use then names instead of index or type (which are not enough). For instance: {code} @PreSecurity("authenticator.login(username, password) public Data getSensitiveData() { // ... } // ... @Named public class Authenticator { public boolean login(String user, String pwd) { return true; } } {code} > Introduce AnnotatedParameter.getJavaParameter() > ----------------------------------------------- > > Key: CDI-481 > URL: https://issues.jboss.org/browse/CDI-481 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Jozef Hartinger > > Make it possible to obtain the Java Reflection object representing the parameter. This is in line with > AnnotatedField.getJavaMember() > AnnotatedMethod.getJavaMember() > AnnotatedConstructor.getJavaMember() > Can be implemented as a default method such as: > {code:JAVA} > default Parameter getJavaParameter() { > Member member = getDeclaringCallable().getJavaMember(); > if (!(member instanceof Executable)) { > throw new IllegalStateException("Parameter does not belong to an executable " + member); > } > Executable executable = (Executable) member; > return executable.getParameters()[getPosition()]; > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antoine at sabot-durand.net Thu Sep 18 19:56:29 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 19 Sep 2014 01:56:29 +0200 Subject: [cdi-dev] Handling of Google Docs document suggestions In-Reply-To: References: Message-ID: Mark, all I changed the rights according to what was decided during our last meeting : http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2014/cdi-dev.2014-09-17-16.01.html Now all people who volunteered to start a doc have edit rights and can change to rights as well. I let most people in ?suggestion? mode to avoid fight over content. But if you feel it?s not necessary you can change it on your doc. Antoine > Le 18 sept. 2014 ? 09:20, Mark Paluch a ?crit : > > Hi Antoine, > all edits in the shared Google Docs are done in suggest mode. Do you have a plan how to achieve an initial document forming the discussion base? Who is in charge of moderating the documents, accepting/declining suggestions? > > Thanks and best regards, Mark > > -- > Mark Paluch > > -- > > PALUCH.biz > Heckenpfad 14 // 69469 Weinheim > T. 0 62 01/65 04 24-0 // F. 0 62 01/65 04 24-9 > mpaluch at paluch.biz > WWW. http://www.paluch.biz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140919/ef6e7136/attachment.html From issues at jboss.org Thu Sep 18 20:24:02 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 18 Sep 2014 20:24:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Add a disposable interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004098#comment-13004098 ] John Ament commented on CDI-457: -------------------------------- [~struberg] if we could write that into the spec, it would eliminate the need here. I suspected that OWB didn't wrap them into contextuals, whereas weld seems to (at least in the 1.1.x line). > Add a disposable interface > -------------------------- > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed. > I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From john.d.ament at gmail.com Thu Sep 18 20:27:42 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 18 Sep 2014 20:27:42 -0400 Subject: [cdi-dev] SE Features Message-ID: Hi Antoine, et. al., I missed this week's meeting due to some last minute scheduling issue, so was unable to attend. I'd like to volunteer to take on the SE integration epic/features, as well as work with Antonin on the JDK8 support. John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140918/c235699f/attachment.html From john.d.ament at gmail.com Thu Sep 18 21:31:53 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 18 Sep 2014 21:31:53 -0400 Subject: [cdi-dev] Binary compatibility and removing classes Message-ID: Hi all Was reading through the log from this past meeting. To comment on a couple of points: - In JMS 2.0 we really wanted to remove the old Queue and Topic based interfaces. We received a lot of push back from even deprecating them, and the most that could be done was to add a comment to the javadoc dissuading people from using them and only keeping them around for legacy purposes. Similar to how @New is stuck around, probably forever, any existing classes need to stick around forever. When it comes to pruning, the pruning is around a technology and not just a small set of classes within a JSR. - In JDK8, they fixed the binary compatibility issue w/ default methods. Since CDI 2.0 should be targeting a Java 8 runtime, can we leverage that for binary compatibility, by saying any new methods we add to interfaces will be default methods some ambiguous/not very useful implementation? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140918/2da34119/attachment.html From issues at jboss.org Fri Sep 19 02:37:02 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 19 Sep 2014 02:37:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Add a disposable interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004122#comment-13004122 ] Mark Struberg commented on CDI-457: ----------------------------------- Not sure if this in line with the spec. See 5.4 Client Proxies: {quote} Client proxies are never required for a bean whose scope is a pseudo-scope such as @Dependent. {quote} If we would introduce a special way to destroy them, then we MUST keep track of them. But this is exactly what we should not need to do for dependent beans... > Add a disposable interface > -------------------------- > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed. > I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 03:09:03 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 19 Sep 2014 03:09:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Add a disposable interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004143#comment-13004143 ] Martin Kouba commented on CDI-457: ---------------------------------- [~meetoblivion] Well, I still don't understand why the new interface is needed. {quote} @UnManaged would be a new annotation indicating that the returned object is not contextual {quote} IMO does not make sense, if you inject dependent SomeClass into some normal-scoped bean, it's not non-contextual. {quote} Disposable object goes out of scope. {quote} What does it mean? How would this work? {quote} I suspected that OWB didn't wrap them into contextuals, whereas weld seems to (at least in the 1.1.x line). {quote} Weld returns a subclass if an interceptor or decorator is associated. Did you mean this by "wrapping into contextuals"? > Add a disposable interface > -------------------------- > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed. > I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From tremes at redhat.com Fri Sep 19 05:57:34 2014 From: tremes at redhat.com (Tomas Remes) Date: Fri, 19 Sep 2014 05:57:34 -0400 (EDT) Subject: [cdi-dev] [cdi-tck] CDI TCK 1.2.2.Final and 1.1.5.Final released In-Reply-To: <1441317576.19080835.1411114257168.JavaMail.zimbra@redhat.com> References: <1441317576.19080835.1411114257168.JavaMail.zimbra@redhat.com> Message-ID: <1933263147.19197558.1411120654768.JavaMail.zimbra@redhat.com> Hi all! CDI TCK 1.2.2.Final and 1.1.5.Final were released. Distribution bundles are available at [1] as usual. The new CDI TCK mailing list (cdi-tck at lists.jboss.org) was established so you can subscribe yourself at [2]. This is going to be the main information channel (along with JIRA of course) for CDI TCK from now. Thank's [1] http://sourceforge.net/projects/jboss/files/CDI-TCK/ [2] https://lists.jboss.org/mailman/listinfo/cdi-tck -- Tomas Remes From pmuir at redhat.com Fri Sep 19 10:10:01 2014 From: pmuir at redhat.com (Pete Muir) Date: Fri, 19 Sep 2014 15:10:01 +0100 Subject: [cdi-dev] Binary compatibility and removing classes In-Reply-To: References: Message-ID: On 19 Sep 2014, at 02:31, John D. Ament wrote: > Hi all > > Was reading through the log from this past meeting. To comment on a couple of points: > > - In JMS 2.0 we really wanted to remove the old Queue and Topic based interfaces. We received a lot of push back from even deprecating them, and the most that could be done was to add a comment to the javadoc dissuading people from using them and only keeping them around for legacy purposes. Similar to how @New is stuck around, probably forever, any existing classes need to stick around forever. When it comes to pruning, the pruning is around a technology and not just a small set of classes within a JSR. Agreed, this is correct, and Antoine and I are aware of this and will make sure this is what happens. > > - In JDK8, they fixed the binary compatibility issue w/ default methods. Since CDI 2.0 should be targeting a Java 8 runtime, can we leverage that for binary compatibility, by saying any new methods we add to interfaces will be default methods some ambiguous/not very useful implementation? Yes, if we decide to target Java 8. > > John > _______________________________________________ > 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 Sat Sep 20 08:39:02 2014 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Sat, 20 Sep 2014 08:39:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-255) Support for Implicit Producers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002319#comment-13002319 ] Antonio Goncalves edited comment on CDI-255 at 9/20/14 8:38 AM: ---------------------------------------------------------------- When you look at all the Java EE 7 specs, you don't find much : *Bean Validation 1.1* (? 10.3. Context and Dependency Injection (CDI) integration) {code} @Inject ValidatorFactory; @Inject Validator; {code} *JMS 2.0* (? 12.4.3. Injection syntax) {code} @Inject private JMSContext context; {code} So definitely a section on Java EE about implicit producers BTW, in the Java EE 7 spec there is *only one single* line of code showing {{@Inject}} Other Java EE objects that could be implicitelly produced : {code} @Inject Principal currentUser; // From JAAS @Inject FacesContext facesContext; // From JSF @Inject EntityManager em; // From JPA, handy when there is only one persistence unit {code} was (Author: agoncal): When you look at all the Java EE 7 specs, you don't find much : *Bean Validation 1.1* (? 10.3. Context and Dependency Injection (CDI) integration) {code} @Inject ValidatorFactory; @Inject Validator; {code} *JMS 2.0* (? 12.4.3. Injection syntax) {code} @Inject private JMSContext context; {code} So definitely a section on Java EE about implicit producers BTW, in the Java EE 7 spec there is *only one single* line of code showing {{@Inject}} > Support for Implicit Producers > ------------------------------ > > Key: CDI-255 > URL: https://issues.jboss.org/browse/CDI-255 > Project: CDI Specification Issues > Issue Type: Tracker > Affects Versions: 1.0 > Reporter: Pete Muir > > An implicit producer could be registered for every unambiguous resource the Java EE container knows about. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 20 09:14:02 2014 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Sat, 20 Sep 2014 09:14:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-255) Support for Implicit Producers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002319#comment-13002319 ] Antonio Goncalves edited comment on CDI-255 at 9/20/14 9:13 AM: ---------------------------------------------------------------- When you look at all the Java EE 7 specs, you don't find much : *Bean Validation 1.1* (? 10.3. Context and Dependency Injection (CDI) integration) {code} @Inject ValidatorFactory; @Inject Validator; {code} *JMS 2.0* (? 12.4.3. Injection syntax) {code} @Inject private JMSContext context; {code} *CDI 1.2* (3.8. Additional built-in beans) A Java EE or embeddable EJB container must provide the following built-in beans, all of which have qualifier {{@Default}}: ? a bean with bean type {{javax.transaction.UserTransaction}}, allowing injection of a reference to the JTA UserTransaction, and ? a bean with bean type {{javax.security.Principal}}, allowing injection of a Principal representing the current caller identity. A servlet container must provide the following built-in beans, all of which have qualifier @Default: ? a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the {{HttpServletRequest}} ? a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the {{HttpSession}}, ? a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the {{ServletContext}}, BTW, in the Java EE 7 spec there is *only one single* line of code showing {{@Inject}} Other Java EE objects that could be implicitly produced : {code} @Inject FacesContext facesContext; // From JSF @Inject EntityManager em; // From JPA, handy when there is only one persistence unit {code} was (Author: agoncal): When you look at all the Java EE 7 specs, you don't find much : *Bean Validation 1.1* (? 10.3. Context and Dependency Injection (CDI) integration) {code} @Inject ValidatorFactory; @Inject Validator; {code} *JMS 2.0* (? 12.4.3. Injection syntax) {code} @Inject private JMSContext context; {code} So definitely a section on Java EE about implicit producers BTW, in the Java EE 7 spec there is *only one single* line of code showing {{@Inject}} Other Java EE objects that could be implicitelly produced : {code} @Inject Principal currentUser; // From JAAS @Inject FacesContext facesContext; // From JSF @Inject EntityManager em; // From JPA, handy when there is only one persistence unit {code} > Support for Implicit Producers > ------------------------------ > > Key: CDI-255 > URL: https://issues.jboss.org/browse/CDI-255 > Project: CDI Specification Issues > Issue Type: Tracker > Affects Versions: 1.0 > Reporter: Pete Muir > > An implicit producer could be registered for every unambiguous resource the Java EE container knows about. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 20 09:14:03 2014 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Sat, 20 Sep 2014 09:14:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-255) Support for Implicit Producers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002319#comment-13002319 ] Antonio Goncalves edited comment on CDI-255 at 9/20/14 9:13 AM: ---------------------------------------------------------------- When you look at all the Java EE 7 specs, you don't find much : *Bean Validation 1.1* (? 10.3. Context and Dependency Injection (CDI) integration) {code} @Inject ValidatorFactory; @Inject Validator; {code} *JMS 2.0* (? 12.4.3. Injection syntax) {code} @Inject private JMSContext context; {code} *CDI 1.2* (3.8. Additional built-in beans) A Java EE or embeddable EJB container must provide the following built-in beans, all of which have qualifier {{@Default}}: * a bean with bean type {{javax.transaction.UserTransaction}}, allowing injection of a reference to the JTA UserTransaction, and * a bean with bean type {{javax.security.Principal}}, allowing injection of a Principal representing the current caller identity. A servlet container must provide the following built-in beans, all of which have qualifier @Default: * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the {{HttpServletRequest}} * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the {{HttpSession}}, * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the {{ServletContext}}, BTW, in the Java EE 7 spec there is *only one single* line of code showing {{@Inject}} Other Java EE objects that could be implicitly produced : {code} @Inject FacesContext facesContext; // From JSF @Inject EntityManager em; // From JPA, handy when there is only one persistence unit {code} was (Author: agoncal): When you look at all the Java EE 7 specs, you don't find much : *Bean Validation 1.1* (? 10.3. Context and Dependency Injection (CDI) integration) {code} @Inject ValidatorFactory; @Inject Validator; {code} *JMS 2.0* (? 12.4.3. Injection syntax) {code} @Inject private JMSContext context; {code} *CDI 1.2* (3.8. Additional built-in beans) A Java EE or embeddable EJB container must provide the following built-in beans, all of which have qualifier {{@Default}}: ? a bean with bean type {{javax.transaction.UserTransaction}}, allowing injection of a reference to the JTA UserTransaction, and ? a bean with bean type {{javax.security.Principal}}, allowing injection of a Principal representing the current caller identity. A servlet container must provide the following built-in beans, all of which have qualifier @Default: ? a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the {{HttpServletRequest}} ? a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the {{HttpSession}}, ? a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the {{ServletContext}}, BTW, in the Java EE 7 spec there is *only one single* line of code showing {{@Inject}} Other Java EE objects that could be implicitly produced : {code} @Inject FacesContext facesContext; // From JSF @Inject EntityManager em; // From JPA, handy when there is only one persistence unit {code} > Support for Implicit Producers > ------------------------------ > > Key: CDI-255 > URL: https://issues.jboss.org/browse/CDI-255 > Project: CDI Specification Issues > Issue Type: Tracker > Affects Versions: 1.0 > Reporter: Pete Muir > > An implicit producer could be registered for every unambiguous resource the Java EE container knows about. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From radhakrishnan.mohan at gmail.com Sat Sep 20 11:21:21 2014 From: radhakrishnan.mohan at gmail.com (Mohan Radhakrishnan) Date: Sat, 20 Sep 2014 20:51:21 +0530 Subject: [cdi-dev] Controlling the Interceptor chain Message-ID: Hi, I have read the older CDI and interceptor spec. but not very thoroughly. Does control over how methods are intercepted using the following rules make it more useful ? 1. Intercept only the top-level call and not recursive calls. 2. Intercept and decorate "call 1" if it happens within "call 2" and not "call 3". Specify one type of combination of interceptions but not the other. I hope these are not orthogonal to the spec. They are features of AOP I know. Thanks, Mohan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140920/acd2570e/attachment.html From pmuir at redhat.com Mon Sep 22 05:37:44 2014 From: pmuir at redhat.com (Pete Muir) Date: Mon, 22 Sep 2014 10:37:44 +0100 Subject: [cdi-dev] Controlling the Interceptor chain In-Reply-To: References: Message-ID: Hi Mohan, This is probably better discussed on the Interceptors expert group. Not sure how that is functioning this time around, will try to check. Pete On 20 Sep 2014, at 16:21, Mohan Radhakrishnan wrote: > Hi, > I have read the older CDI and interceptor spec. but not very thoroughly. > > Does control over how methods are intercepted using the following rules make it more useful ? > > 1. Intercept only the top-level call and not recursive calls. > > 2. Intercept and decorate "call 1" if it happens within "call 2" and not "call 3". Specify one type of combination of interceptions but not the other. > > I hope these are not orthogonal to the spec. They are features of AOP I know. > > > Thanks, > Mohan > _______________________________________________ > 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 Mon Sep 22 06:39:16 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 22 Sep 2014 12:39:16 +0200 Subject: [cdi-dev] CDI F2F meeting Message-ID: Hi All, To have a ?physical? kick off for CDI 2.0 we organised a Face to Face meeting the 15th and 16th October. This meeting will take place in Brno Red Hat office (in Czech Republic). All the community is invited Red Hat will offer lunches for the 2 days and dinner on the 15th. Transportation and hotel is note included Agenda will include : - Work on the different workshop, starting with the less obvious (parts, Contexts and SPI evolution) - How to contribute to TCK and RI - Start to specify new features - Roadmap for Weld 3.0 (the CDI RI) We are off course open to other topics link to CDI and CDI 2.0. If you are interested or have question please let me know. We?ll talk about this on the next wednesday meeting. Antoine From antonio.goncalves at gmail.com Mon Sep 22 07:03:39 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 22 Sep 2014 13:03:39 +0200 Subject: [cdi-dev] CDI F2F meeting In-Reply-To: References: Message-ID: Hi all, Face to faces meetings are a really great idea. But let me give you my 2 cents about this : Most self-employed contractors, like me, need to pay for the travel and expenses. Which it's fine, I do not expect RedHat to pay for this ;o) But on top of that, we need to take a few days off work, which increases the amount of the bill. In this case, Wednesday/Thursday which are in the middle of the week (and leaves Friday off (another day without billing), or returning to work (which is a bit rough). Why not having those meetings on *Friday/Saturday* ? Contractors would only loose a day of work, and can enjoy the week-end by relaxing on Sunday. What do you all think ? Antonio On Mon, Sep 22, 2014 at 12:39 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi All, > > > To have a ?physical? kick off for CDI 2.0 we organised a Face to Face > meeting the 15th and 16th October. This meeting will take place in Brno Red > Hat office (in Czech Republic). All the community is invited > Red Hat will offer lunches for the 2 days and dinner on the 15th. > Transportation and hotel is note included > Agenda will include : > > - Work on the different workshop, starting with the less obvious (parts, > Contexts and SPI evolution) > - How to contribute to TCK and RI > - Start to specify new features > - Roadmap for Weld 3.0 (the CDI RI) > > We are off course open to other topics link to CDI and CDI 2.0. > > If you are interested or have question please let me know. We?ll talk > about this on the next wednesday 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. -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140922/96e63ee0/attachment.html From antoine at sabot-durand.net Mon Sep 22 09:24:27 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 22 Sep 2014 15:24:27 +0200 Subject: [cdi-dev] CDI F2F meeting In-Reply-To: References: Message-ID: Hi Antonio, In an ideal world we should have done something like your suggestion or at least consult people before planning this. Now there are constraints that go beyond our reach here. The first one being that these dates were more or less decided before the EG formation (even before the CDI 2.0 proposal was accepted by the JCP). I know it?s not perfect, but we have this opportunity to meet at this time and place. Should we organise other meeting later (in 2015), we?ll try to take your in put into consideration. Antoine > Le 22 sept. 2014 ? 13:03, Antonio Goncalves a ?crit : > > Hi all, > > Face to faces meetings are a really great idea. But let me give you my 2 cents about this : > > Most self-employed contractors, like me, need to pay for the travel and expenses. Which it's fine, I do not expect RedHat to pay for this ;o) But on top of that, we need to take a few days off work, which increases the amount of the bill. In this case, Wednesday/Thursday which are in the middle of the week (and leaves Friday off (another day without billing), or returning to work (which is a bit rough). > > Why not having those meetings on Friday/Saturday ? Contractors would only loose a day of work, and can enjoy the week-end by relaxing on Sunday. > > What do you all think ? > > Antonio > > On Mon, Sep 22, 2014 at 12:39 PM, Antoine Sabot-Durand > wrote: > Hi All, > > > To have a ?physical? kick off for CDI 2.0 we organised a Face to Face meeting the 15th and 16th October. This meeting will take place in Brno Red Hat office (in Czech Republic). All the community is invited > Red Hat will offer lunches for the 2 days and dinner on the 15th. Transportation and hotel is note included > Agenda will include : > > - Work on the different workshop, starting with the less obvious (parts, Contexts and SPI evolution) > - How to contribute to TCK and RI > - Start to specify new features > - Roadmap for Weld 3.0 (the CDI RI) > > We are off course open to other topics link to CDI and CDI 2.0. > > If you are interested or have question please let me know. We?ll talk about this on the next wednesday 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. > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140922/baa68b33/attachment.html From antonio.goncalves at gmail.com Mon Sep 22 09:30:24 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 22 Sep 2014 15:30:24 +0200 Subject: [cdi-dev] CDI F2F meeting In-Reply-To: References: Message-ID: Thanks. Unfortunately I won't be able to attend on October, but if you take my wish (and others?) in consideration and plan another meeting on Friday/Saturday later in 2015, I will be pleased to assist. Antonio On Mon, Sep 22, 2014 at 3:24 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi Antonio, > > In an ideal world we should have done something like your suggestion or at > least consult people before planning this. Now there are constraints that > go beyond our reach here. The first one being that these dates were more or > less decided before the EG formation (even before the CDI 2.0 proposal was > accepted by the JCP). > I know it?s not perfect, but we have this opportunity to meet at this time > and place. Should we organise other meeting later (in 2015), we?ll try to > take your in put into consideration. > > Antoine > > > > Le 22 sept. 2014 ? 13:03, Antonio Goncalves > a ?crit : > > Hi all, > > Face to faces meetings are a really great idea. But let me give you my 2 > cents about this : > > Most self-employed contractors, like me, need to pay for the travel and > expenses. Which it's fine, I do not expect RedHat to pay for this ;o) But > on top of that, we need to take a few days off work, which increases the > amount of the bill. In this case, Wednesday/Thursday which are in the > middle of the week (and leaves Friday off (another day without billing), or > returning to work (which is a bit rough). > > Why not having those meetings on *Friday/Saturday* ? Contractors would > only loose a day of work, and can enjoy the week-end by relaxing on Sunday. > > What do you all think ? > > Antonio > > On Mon, Sep 22, 2014 at 12:39 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi All, >> >> >> To have a ?physical? kick off for CDI 2.0 we organised a Face to Face >> meeting the 15th and 16th October. This meeting will take place in Brno Red >> Hat office (in Czech Republic). All the community is invited >> Red Hat will offer lunches for the 2 days and dinner on the 15th. >> Transportation and hotel is note included >> Agenda will include : >> >> - Work on the different workshop, starting with the less obvious (parts, >> Contexts and SPI evolution) >> - How to contribute to TCK and RI >> - Start to specify new features >> - Roadmap for Weld 3.0 (the CDI RI) >> >> We are off course open to other topics link to CDI and CDI 2.0. >> >> If you are interested or have question please let me know. We?ll talk >> about this on the next wednesday 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. > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > > > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140922/c265cf8a/attachment-0001.html From john.d.ament at gmail.com Mon Sep 22 09:45:45 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 22 Sep 2014 09:45:45 -0400 Subject: [cdi-dev] CDI F2F meeting In-Reply-To: References: Message-ID: I have to side with Antonio on this one. For me, getting a visa and passport together in 4 weeks time is just not realistic, especially for a two day trip to Czech Republic. Hopefully we can do some small kick off at JavaOne though :-) On Mon, Sep 22, 2014 at 9:30 AM, Antonio Goncalves < antonio.goncalves at gmail.com> wrote: > Thanks. > > Unfortunately I won't be able to attend on October, but if you take my > wish (and others?) in consideration and plan another meeting on > Friday/Saturday later in 2015, I will be pleased to assist. > > Antonio > > On Mon, Sep 22, 2014 at 3:24 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi Antonio, >> >> In an ideal world we should have done something like your suggestion or >> at least consult people before planning this. Now there are constraints >> that go beyond our reach here. The first one being that these dates were >> more or less decided before the EG formation (even before the CDI 2.0 >> proposal was accepted by the JCP). >> I know it?s not perfect, but we have this opportunity to meet at this >> time and place. Should we organise other meeting later (in 2015), we?ll try >> to take your in put into consideration. >> >> Antoine >> >> >> >> Le 22 sept. 2014 ? 13:03, Antonio Goncalves >> a ?crit : >> >> Hi all, >> >> Face to faces meetings are a really great idea. But let me give you my 2 >> cents about this : >> >> Most self-employed contractors, like me, need to pay for the travel and >> expenses. Which it's fine, I do not expect RedHat to pay for this ;o) But >> on top of that, we need to take a few days off work, which increases the >> amount of the bill. In this case, Wednesday/Thursday which are in the >> middle of the week (and leaves Friday off (another day without billing), or >> returning to work (which is a bit rough). >> >> Why not having those meetings on *Friday/Saturday* ? Contractors would >> only loose a day of work, and can enjoy the week-end by relaxing on Sunday. >> >> What do you all think ? >> >> Antonio >> >> On Mon, Sep 22, 2014 at 12:39 PM, Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>> Hi All, >>> >>> >>> To have a ?physical? kick off for CDI 2.0 we organised a Face to Face >>> meeting the 15th and 16th October. This meeting will take place in Brno Red >>> Hat office (in Czech Republic). All the community is invited >>> Red Hat will offer lunches for the 2 days and dinner on the 15th. >>> Transportation and hotel is note included >>> Agenda will include : >>> >>> - Work on the different workshop, starting with the less obvious (parts, >>> Contexts and SPI evolution) >>> - How to contribute to TCK and RI >>> - Start to specify new features >>> - Roadmap for Weld 3.0 (the CDI RI) >>> >>> We are off course open to other topics link to CDI and CDI 2.0. >>> >>> If you are interested or have question please let me know. We?ll talk >>> about this on the next wednesday 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. >> >> >> >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter >> | LinkedIn >> | Pluralsight >> | Paris >> JUG | Devoxx France >> >> >> > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > > _______________________________________________ > 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/20140922/3e503436/attachment.html From struberg at yahoo.de Mon Sep 22 10:18:15 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 22 Sep 2014 15:18:15 +0100 Subject: [cdi-dev] CDI F2F meeting In-Reply-To: References: Message-ID: <1411395495.62442.YahooMailNeo@web28904.mail.ir2.yahoo.com> I think I can make it. LieGrue, strub On Monday, 22 September 2014, 15:46, John D. Ament wrote: > > >I have to side with Antonio on this one. For me, getting a visa and passport together in 4 weeks time is just not realistic, especially for a two day trip to Czech Republic. Hopefully we can do some small kick off at JavaOne though :-) > > >On Mon, Sep 22, 2014 at 9:30 AM, Antonio Goncalves wrote: > >Thanks. >> >> >>Unfortunately I won't be able to attend on October, but if you take my wish (and others?) in consideration and plan another meeting on Friday/Saturday later in 2015, I will be pleased to assist. >> >> >>Antonio >> >> >>On Mon, Sep 22, 2014 at 3:24 PM, Antoine Sabot-Durand wrote: >> >>Hi Antonio, >>> >>> >>>In an ideal world we should have done something like your suggestion or at least consult people before planning this. Now there are constraints that go beyond our reach here. The first one being that these dates were more or less decided before the EG formation (even before the CDI 2.0 proposal was accepted by the JCP). >>>I know it?s not perfect, but we have this opportunity to meet at this time and place. Should we organise other meeting later (in 2015), we?ll try to take your in put into consideration. >>> >>> >>>Antoine >>> >>> >>> >>> >>> >>>Le 22 sept. 2014 ? 13:03, Antonio Goncalves a ?crit : >>>> >>>> >>>>Hi all, >>>> >>>> >>>>Face to faces meetings are a really great idea. But let me give you my 2 cents about this : >>>> >>>> >>>>Most self-employed contractors, like me, need to pay for the travel and expenses. Which it's fine, I do not expect RedHat to pay for this ;o) But on top of that, we need to take a few days off work, which increases the amount of the bill. In this case, Wednesday/Thursday which are in the middle of the week (and leaves Friday off (another day without billing), or returning to work (which is a bit rough). >>>> >>>> >>>>Why not having those meetings on Friday/Saturday ? Contractors would only loose a day of work, and can enjoy the week-end by relaxing on Sunday. >>>> >>>> >>>>What do you all think ? >>>> >>>> >>>>Antonio >>>> >>>> >>>>On Mon, Sep 22, 2014 at 12:39 PM, Antoine Sabot-Durand wrote: >>>> >>>>Hi All, >>>>> >>>>> >>>>>To have a ?physical? kick off for CDI 2.0 we organised a Face to Face meeting the 15th and 16th October. This meeting will take place in Brno Red Hat office (in Czech Republic). All the community is invited >>>>>Red Hat will offer lunches for the 2 days and dinner on the 15th. Transportation and hotel is note included >>>>>Agenda will include : >>>>> >>>>>- Work on the different workshop, starting with the less obvious (parts, Contexts and SPI evolution) >>>>>- How to contribute to TCK and RI >>>>>- Start to specify new features >>>>>- Roadmap for Weld 3.0 (the CDI RI) >>>>> >>>>>We are off course open to other topics link to CDI and CDI 2.0. >>>>> >>>>>If you are interested or have question please let me know. We?ll talk about this on the next wednesday 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. >>>> >>>> >>>> >>>>-- >>>> >>>>Antonio Goncalves >>>>Software architect, Java Champion and Pluralsight author >>>> >>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >>> >> >> >> >>-- >> >>Antonio Goncalves >>Software architect, Java Champion and Pluralsight author >> >>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >>_______________________________________________ >>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 Mon Sep 22 14:58:42 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 22 Sep 2014 20:58:42 +0200 Subject: [cdi-dev] CDI meeting and work session during Java One Message-ID: Hi all, We can have a room for a CDI meeting during Java One. It should be on Thursday the whole day or half day. Who will be there and is interested ? Antoine From radhakrishnan.mohan at gmail.com Mon Sep 22 23:38:10 2014 From: radhakrishnan.mohan at gmail.com (Mohan Radhakrishnan) Date: Tue, 23 Sep 2014 09:08:10 +0530 Subject: [cdi-dev] Controlling the Interceptor chain In-Reply-To: References: Message-ID: Hi Pete, What is the general roadmap for the AOP and Interceptor section of CDI 2.0 ? Is that what the workshops are going to figure out ? Thanks, Mohan On Mon, Sep 22, 2014 at 3:07 PM, Pete Muir wrote: > Hi Mohan, > > This is probably better discussed on the Interceptors expert group. Not > sure how that is functioning this time around, will try to check. > > Pete > > On 20 Sep 2014, at 16:21, Mohan Radhakrishnan < > radhakrishnan.mohan at gmail.com> wrote: > > > Hi, > > I have read the older CDI and interceptor spec. but not very > thoroughly. > > > > Does control over how methods are intercepted using the following rules > make it more useful ? > > > > 1. Intercept only the top-level call and not recursive calls. > > > > 2. Intercept and decorate "call 1" if it happens within "call 2" and not > "call 3". Specify one type of combination of interceptions but not the > other. > > > > I hope these are not orthogonal to the spec. They are features of AOP I > know. > > > > > > Thanks, > > Mohan > > _______________________________________________ > > 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/20140923/b3854f38/attachment-0001.html From thjanssen123 at gmail.com Tue Sep 23 02:42:35 2014 From: thjanssen123 at gmail.com (Thorben Janssen) Date: Tue, 23 Sep 2014 08:42:35 +0200 Subject: [cdi-dev] CDI F2F meeting In-Reply-To: <1411395495.62442.YahooMailNeo@web28904.mail.ir2.yahoo.com> References: <1411395495.62442.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: I will not be able to attend :( I am doing this in my free time and I have no vacation left for this year. Regards, Thorben -- *Thorben Janssen* @thjanssen123 www.thoughts-on-java.org 2014-09-22 16:18 GMT+02:00 Mark Struberg : > I think I can make it. > > LieGrue, > strub > > > On Monday, 22 September 2014, 15:46, John D. Ament > wrote: > > > > > > > >I have to side with Antonio on this one. For me, getting a visa and > passport together in 4 weeks time is just not realistic, especially for a > two day trip to Czech Republic. Hopefully we can do some small kick off at > JavaOne though :-) > > > > > >On Mon, Sep 22, 2014 at 9:30 AM, Antonio Goncalves < > antonio.goncalves at gmail.com> wrote: > > > >Thanks. > >> > >> > >>Unfortunately I won't be able to attend on October, but if you take my > wish (and others?) in consideration and plan another meeting on > Friday/Saturday later in 2015, I will be pleased to assist. > >> > >> > >>Antonio > >> > >> > >>On Mon, Sep 22, 2014 at 3:24 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> > >>Hi Antonio, > >>> > >>> > >>>In an ideal world we should have done something like your suggestion or > at least consult people before planning this. Now there are constraints > that go beyond our reach here. The first one being that these dates were > more or less decided before the EG formation (even before the CDI 2.0 > proposal was accepted by the JCP). > >>>I know it?s not perfect, but we have this opportunity to meet at this > time and place. Should we organise other meeting later (in 2015), we?ll try > to take your in put into consideration. > >>> > >>> > >>>Antoine > >>> > >>> > >>> > >>> > >>> > >>>Le 22 sept. 2014 ? 13:03, Antonio Goncalves < > antonio.goncalves at gmail.com> a ?crit : > >>>> > >>>> > >>>>Hi all, > >>>> > >>>> > >>>>Face to faces meetings are a really great idea. But let me give you my > 2 cents about this : > >>>> > >>>> > >>>>Most self-employed contractors, like me, need to pay for the travel > and expenses. Which it's fine, I do not expect RedHat to pay for this ;o) > But on top of that, we need to take a few days off work, which increases > the amount of the bill. In this case, Wednesday/Thursday which are in the > middle of the week (and leaves Friday off (another day without billing), or > returning to work (which is a bit rough). > >>>> > >>>> > >>>>Why not having those meetings on Friday/Saturday ? Contractors would > only loose a day of work, and can enjoy the week-end by relaxing on Sunday. > >>>> > >>>> > >>>>What do you all think ? > >>>> > >>>> > >>>>Antonio > >>>> > >>>> > >>>>On Mon, Sep 22, 2014 at 12:39 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >>>> > >>>>Hi All, > >>>>> > >>>>> > >>>>>To have a ?physical? kick off for CDI 2.0 we organised a Face to Face > meeting the 15th and 16th October. This meeting will take place in Brno Red > Hat office (in Czech Republic). All the community is invited > >>>>>Red Hat will offer lunches for the 2 days and dinner on the 15th. > Transportation and hotel is note included > >>>>>Agenda will include : > >>>>> > >>>>>- Work on the different workshop, starting with the less obvious > (parts, Contexts and SPI evolution) > >>>>>- How to contribute to TCK and RI > >>>>>- Start to specify new features > >>>>>- Roadmap for Weld 3.0 (the CDI RI) > >>>>> > >>>>>We are off course open to other topics link to CDI and CDI 2.0. > >>>>> > >>>>>If you are interested or have question please let me know. We?ll talk > about this on the next wednesday 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. > >>>> > >>>> > >>>> > >>>>-- > >>>> > >>>>Antonio Goncalves > >>>>Software architect, Java Champion and Pluralsight author > >>>> > >>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > >>> > >> > >> > >> > >>-- > >> > >>Antonio Goncalves > >>Software architect, Java Champion and Pluralsight author > >> > >>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > >>_______________________________________________ > >>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. > > > > > > _______________________________________________ > 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/20140923/d7716fa8/attachment.html From antonio.goncalves at gmail.com Tue Sep 23 03:10:55 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Tue, 23 Sep 2014 09:10:55 +0200 Subject: [cdi-dev] CDI F2F meeting In-Reply-To: References: <1411395495.62442.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Thorben, and what do you think of my proposition of including week-ends (like Friday/Saturday for example) ? Would that fit you better ? On Tue, Sep 23, 2014 at 8:42 AM, Thorben Janssen wrote: > I will not be able to attend :( > I am doing this in my free time and I have no vacation left for this year. > > Regards, > Thorben > > -- > *Thorben Janssen* > > @thjanssen123 > www.thoughts-on-java.org > > 2014-09-22 16:18 GMT+02:00 Mark Struberg : > >> I think I can make it. >> >> LieGrue, >> strub >> >> >> On Monday, 22 September 2014, 15:46, John D. Ament < >> john.d.ament at gmail.com> wrote: >> >> >> > >> > >> >I have to side with Antonio on this one. For me, getting a visa and >> passport together in 4 weeks time is just not realistic, especially for a >> two day trip to Czech Republic. Hopefully we can do some small kick off at >> JavaOne though :-) >> > >> > >> >On Mon, Sep 22, 2014 at 9:30 AM, Antonio Goncalves < >> antonio.goncalves at gmail.com> wrote: >> > >> >Thanks. >> >> >> >> >> >>Unfortunately I won't be able to attend on October, but if you take my >> wish (and others?) in consideration and plan another meeting on >> Friday/Saturday later in 2015, I will be pleased to assist. >> >> >> >> >> >>Antonio >> >> >> >> >> >>On Mon, Sep 22, 2014 at 3:24 PM, Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >> >> >>Hi Antonio, >> >>> >> >>> >> >>>In an ideal world we should have done something like your suggestion >> or at least consult people before planning this. Now there are constraints >> that go beyond our reach here. The first one being that these dates were >> more or less decided before the EG formation (even before the CDI 2.0 >> proposal was accepted by the JCP). >> >>>I know it?s not perfect, but we have this opportunity to meet at this >> time and place. Should we organise other meeting later (in 2015), we?ll try >> to take your in put into consideration. >> >>> >> >>> >> >>>Antoine >> >>> >> >>> >> >>> >> >>> >> >>> >> >>>Le 22 sept. 2014 ? 13:03, Antonio Goncalves < >> antonio.goncalves at gmail.com> a ?crit : >> >>>> >> >>>> >> >>>>Hi all, >> >>>> >> >>>> >> >>>>Face to faces meetings are a really great idea. But let me give you >> my 2 cents about this : >> >>>> >> >>>> >> >>>>Most self-employed contractors, like me, need to pay for the travel >> and expenses. Which it's fine, I do not expect RedHat to pay for this ;o) >> But on top of that, we need to take a few days off work, which increases >> the amount of the bill. In this case, Wednesday/Thursday which are in the >> middle of the week (and leaves Friday off (another day without billing), or >> returning to work (which is a bit rough). >> >>>> >> >>>> >> >>>>Why not having those meetings on Friday/Saturday ? Contractors would >> only loose a day of work, and can enjoy the week-end by relaxing on Sunday. >> >>>> >> >>>> >> >>>>What do you all think ? >> >>>> >> >>>> >> >>>>Antonio >> >>>> >> >>>> >> >>>>On Mon, Sep 22, 2014 at 12:39 PM, Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>>> >> >>>>Hi All, >> >>>>> >> >>>>> >> >>>>>To have a ?physical? kick off for CDI 2.0 we organised a Face to >> Face meeting the 15th and 16th October. This meeting will take place in >> Brno Red Hat office (in Czech Republic). All the community is invited >> >>>>>Red Hat will offer lunches for the 2 days and dinner on the 15th. >> Transportation and hotel is note included >> >>>>>Agenda will include : >> >>>>> >> >>>>>- Work on the different workshop, starting with the less obvious >> (parts, Contexts and SPI evolution) >> >>>>>- How to contribute to TCK and RI >> >>>>>- Start to specify new features >> >>>>>- Roadmap for Weld 3.0 (the CDI RI) >> >>>>> >> >>>>>We are off course open to other topics link to CDI and CDI 2.0. >> >>>>> >> >>>>>If you are interested or have question please let me know. We?ll >> talk about this on the next wednesday 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. >> >>>> >> >>>> >> >>>> >> >>>>-- >> >>>> >> >>>>Antonio Goncalves >> >>>>Software architect, Java Champion and Pluralsight author >> >>>> >> >>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx >> France >> >>> >> >> >> >> >> >> >> >>-- >> >> >> >>Antonio Goncalves >> >>Software architect, Java Champion and Pluralsight author >> >> >> >>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >> >>_______________________________________________ >> >>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. >> > >> > >> >> _______________________________________________ >> 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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140923/94dcf267/attachment-0001.html From thjanssen123 at gmail.com Tue Sep 23 03:27:07 2014 From: thjanssen123 at gmail.com (Thorben Janssen) Date: Tue, 23 Sep 2014 09:27:07 +0200 Subject: [cdi-dev] CDI F2F meeting In-Reply-To: References: <1411395495.62442.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: Yes, that would fit better (in general). -- *Thorben Janssen* @thjanssen123 www.thoughts-on-java.org 2014-09-23 9:10 GMT+02:00 Antonio Goncalves : > Thorben, and what do you think of my proposition of including week-ends > (like Friday/Saturday for example) ? Would that fit you better ? > > On Tue, Sep 23, 2014 at 8:42 AM, Thorben Janssen > wrote: > >> I will not be able to attend :( >> I am doing this in my free time and I have no vacation left for this year. >> >> Regards, >> Thorben >> >> -- >> *Thorben Janssen* >> >> @thjanssen123 >> www.thoughts-on-java.org >> >> 2014-09-22 16:18 GMT+02:00 Mark Struberg : >> >>> I think I can make it. >>> >>> LieGrue, >>> strub >>> >>> >>> On Monday, 22 September 2014, 15:46, John D. Ament < >>> john.d.ament at gmail.com> wrote: >>> >>> >>> > >>> > >>> >I have to side with Antonio on this one. For me, getting a visa and >>> passport together in 4 weeks time is just not realistic, especially for a >>> two day trip to Czech Republic. Hopefully we can do some small kick off at >>> JavaOne though :-) >>> > >>> > >>> >On Mon, Sep 22, 2014 at 9:30 AM, Antonio Goncalves < >>> antonio.goncalves at gmail.com> wrote: >>> > >>> >Thanks. >>> >> >>> >> >>> >>Unfortunately I won't be able to attend on October, but if you take my >>> wish (and others?) in consideration and plan another meeting on >>> Friday/Saturday later in 2015, I will be pleased to assist. >>> >> >>> >> >>> >>Antonio >>> >> >>> >> >>> >>On Mon, Sep 22, 2014 at 3:24 PM, Antoine Sabot-Durand < >>> antoine at sabot-durand.net> wrote: >>> >> >>> >>Hi Antonio, >>> >>> >>> >>> >>> >>>In an ideal world we should have done something like your suggestion >>> or at least consult people before planning this. Now there are constraints >>> that go beyond our reach here. The first one being that these dates were >>> more or less decided before the EG formation (even before the CDI 2.0 >>> proposal was accepted by the JCP). >>> >>>I know it?s not perfect, but we have this opportunity to meet at this >>> time and place. Should we organise other meeting later (in 2015), we?ll try >>> to take your in put into consideration. >>> >>> >>> >>> >>> >>>Antoine >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>Le 22 sept. 2014 ? 13:03, Antonio Goncalves < >>> antonio.goncalves at gmail.com> a ?crit : >>> >>>> >>> >>>> >>> >>>>Hi all, >>> >>>> >>> >>>> >>> >>>>Face to faces meetings are a really great idea. But let me give you >>> my 2 cents about this : >>> >>>> >>> >>>> >>> >>>>Most self-employed contractors, like me, need to pay for the travel >>> and expenses. Which it's fine, I do not expect RedHat to pay for this ;o) >>> But on top of that, we need to take a few days off work, which increases >>> the amount of the bill. In this case, Wednesday/Thursday which are in the >>> middle of the week (and leaves Friday off (another day without billing), or >>> returning to work (which is a bit rough). >>> >>>> >>> >>>> >>> >>>>Why not having those meetings on Friday/Saturday ? Contractors would >>> only loose a day of work, and can enjoy the week-end by relaxing on Sunday. >>> >>>> >>> >>>> >>> >>>>What do you all think ? >>> >>>> >>> >>>> >>> >>>>Antonio >>> >>>> >>> >>>> >>> >>>>On Mon, Sep 22, 2014 at 12:39 PM, Antoine Sabot-Durand < >>> antoine at sabot-durand.net> wrote: >>> >>>> >>> >>>>Hi All, >>> >>>>> >>> >>>>> >>> >>>>>To have a ?physical? kick off for CDI 2.0 we organised a Face to >>> Face meeting the 15th and 16th October. This meeting will take place in >>> Brno Red Hat office (in Czech Republic). All the community is invited >>> >>>>>Red Hat will offer lunches for the 2 days and dinner on the 15th. >>> Transportation and hotel is note included >>> >>>>>Agenda will include : >>> >>>>> >>> >>>>>- Work on the different workshop, starting with the less obvious >>> (parts, Contexts and SPI evolution) >>> >>>>>- How to contribute to TCK and RI >>> >>>>>- Start to specify new features >>> >>>>>- Roadmap for Weld 3.0 (the CDI RI) >>> >>>>> >>> >>>>>We are off course open to other topics link to CDI and CDI 2.0. >>> >>>>> >>> >>>>>If you are interested or have question please let me know. We?ll >>> talk about this on the next wednesday 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. >>> >>>> >>> >>>> >>> >>>> >>> >>>>-- >>> >>>> >>> >>>>Antonio Goncalves >>> >>>>Software architect, Java Champion and Pluralsight author >>> >>>> >>> >>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx >>> France >>> >>> >>> >> >>> >> >>> >> >>> >>-- >>> >> >>> >>Antonio Goncalves >>> >>Software architect, Java Champion and Pluralsight author >>> >> >>> >>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >>> >>_______________________________________________ >>> >>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. >>> > >>> > >>> >>> _______________________________________________ >>> 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. >> > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140923/d1942d12/attachment.html From antonin at stefanutti.fr Tue Sep 23 03:28:40 2014 From: antonin at stefanutti.fr (Antonin Stefanutti) Date: Tue, 23 Sep 2014 07:28:40 +0000 Subject: [cdi-dev] CDI meeting and work session during Java One In-Reply-To: References: Message-ID: <1411457285910.53264@stefanutti.fr> Hi Antoine, I'll be there and in for the meeting. Antonin ________________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of Antoine Sabot-Durand Sent: Monday, September 22, 2014 8:58 PM To: cdi-dev Subject: [cdi-dev] CDI meeting and work session during Java One Hi all, We can have a room for a CDI meeting during Java One. It should be on Thursday the whole day or half day. Who will be there and is interested ? 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 Tue Sep 23 05:05:21 2014 From: pmuir at redhat.com (Pete Muir) Date: Tue, 23 Sep 2014 10:05:21 +0100 Subject: [cdi-dev] Controlling the Interceptor chain In-Reply-To: References: Message-ID: <929C9F01-9604-4FE5-BA09-8E0D4EF72C8B@redhat.com> I asked around, and the suggestion is to make a comment using the users list for the interceptors spec, as described at https://java.net/projects/interceptors-spec/lists Thanks! On 22 Sep 2014, at 10:37, Pete Muir wrote: > Hi Mohan, > > This is probably better discussed on the Interceptors expert group. Not sure how that is functioning this time around, will try to check. > > Pete > > On 20 Sep 2014, at 16:21, Mohan Radhakrishnan wrote: > >> Hi, >> I have read the older CDI and interceptor spec. but not very thoroughly. >> >> Does control over how methods are intercepted using the following rules make it more useful ? >> >> 1. Intercept only the top-level call and not recursive calls. >> >> 2. Intercept and decorate "call 1" if it happens within "call 2" and not "call 3". Specify one type of combination of interceptions but not the other. >> >> I hope these are not orthogonal to the spec. They are features of AOP I know. >> >> >> Thanks, >> Mohan >> _______________________________________________ >> 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/20140923/aeacb2a3/attachment-0001.html From pmuir at redhat.com Tue Sep 23 05:18:06 2014 From: pmuir at redhat.com (Pete Muir) Date: Tue, 23 Sep 2014 10:18:06 +0100 Subject: [cdi-dev] Controlling the Interceptor chain In-Reply-To: References: Message-ID: <9BAD7D1F-9B9F-4AB9-B74A-F1DAF7CAB8E0@redhat.com> Hi Mohan, Yes, the workshops will discuss this. However note that quite a lot of interceptors are shared between Java EE specs, so not under our direct control. So changes in how interceptors work need to be addressed in the interceptors spec? Pete On 23 Sep 2014, at 04:38, Mohan Radhakrishnan wrote: > Hi Pete, > What is the general roadmap for the AOP and Interceptor section of CDI 2.0 ? Is that what the workshops are going to figure out ? > > Thanks, > Mohan > > On Mon, Sep 22, 2014 at 3:07 PM, Pete Muir wrote: > Hi Mohan, > > This is probably better discussed on the Interceptors expert group. Not sure how that is functioning this time around, will try to check. > > Pete > > On 20 Sep 2014, at 16:21, Mohan Radhakrishnan wrote: > > > Hi, > > I have read the older CDI and interceptor spec. but not very thoroughly. > > > > Does control over how methods are intercepted using the following rules make it more useful ? > > > > 1. Intercept only the top-level call and not recursive calls. > > > > 2. Intercept and decorate "call 1" if it happens within "call 2" and not "call 3". Specify one type of combination of interceptions but not the other. > > > > I hope these are not orthogonal to the spec. They are features of AOP I know. > > > > > > Thanks, > > Mohan > > _______________________________________________ > > 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/20140923/ff7c7381/attachment.html From antoine at sabot-durand.net Tue Sep 23 05:21:13 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 23 Sep 2014 11:21:13 +0200 Subject: [cdi-dev] Controlling the Interceptor chain In-Reply-To: <9BAD7D1F-9B9F-4AB9-B74A-F1DAF7CAB8E0@redhat.com> References: <9BAD7D1F-9B9F-4AB9-B74A-F1DAF7CAB8E0@redhat.com> Message-ID: Hi Mohan, As Pete said, it?s not depending only on us. I see the AOP workshop as mean to gather the request we?ll make to the interceptor spec. Regards, Antoine > Le 23 sept. 2014 ? 11:18, Pete Muir a ?crit : > > Hi Mohan, > > Yes, the workshops will discuss this. However note that quite a lot of interceptors are shared between Java EE specs, so not under our direct control. So changes in how interceptors work need to be addressed in the interceptors spec? > > Pete > > On 23 Sep 2014, at 04:38, Mohan Radhakrishnan > wrote: > >> Hi Pete, >> What is the general roadmap for the AOP and Interceptor section of CDI 2.0 ? Is that what the workshops are going to figure out ? >> >> Thanks, >> Mohan >> >> On Mon, Sep 22, 2014 at 3:07 PM, Pete Muir > wrote: >> Hi Mohan, >> >> This is probably better discussed on the Interceptors expert group. Not sure how that is functioning this time around, will try to check. >> >> Pete >> >> On 20 Sep 2014, at 16:21, Mohan Radhakrishnan > wrote: >> >> > Hi, >> > I have read the older CDI and interceptor spec. but not very thoroughly. >> > >> > Does control over how methods are intercepted using the following rules make it more useful ? >> > >> > 1. Intercept only the top-level call and not recursive calls. >> > >> > 2. Intercept and decorate "call 1" if it happens within "call 2" and not "call 3". Specify one type of combination of interceptions but not the other. >> > >> > I hope these are not orthogonal to the spec. They are features of AOP I know. >> > >> > >> > Thanks, >> > Mohan >> > _______________________________________________ >> > 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/20140923/7201c8ad/attachment.html From antoine at sabot-durand.net Tue Sep 23 09:07:32 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 23 Sep 2014 15:07:32 +0200 Subject: [cdi-dev] CDI meeting and work session during Java One In-Reply-To: <1411457285910.53264@stefanutti.fr> References: <1411457285910.53264@stefanutti.fr> Message-ID: <229966F8-2A3D-4F74-8E85-AD1993B64A60@sabot-durand.net> Great! We should be at least 5 ;). Do feel like going for the whole day or only half of it ? Right now the room is free from 9:00am to 9:00pm ;). Can be a true work session but I don?t want you to miss talks. Wdyt ? Antoine From atsticks at gmail.com Wed Sep 24 01:32:51 2014 From: atsticks at gmail.com (Anatole Tresch) Date: Wed, 24 Sep 2014 07:32:51 +0200 Subject: [cdi-dev] CDI meeting and work session during Java One In-Reply-To: References: Message-ID: Hi Antoine I will join, Thursday sounds good. Anatole 2014-09-22 20:58 GMT+02:00 Antoine Sabot-Durand : > Hi all, > > We can have a room for a CDI meeting during Java One. It should be on > Thursday the whole day or half day. Who will be there and is interested ? > > 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. > -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140924/0f9c4b0f/attachment.html From issues at jboss.org Wed Sep 24 04:36:02 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 24 Sep 2014 04:36:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-482) Overloaded version of ObserverMethod.notify() In-Reply-To: References: Message-ID: Jozef Hartinger created CDI-482: ----------------------------------- Summary: Overloaded version of ObserverMethod.notify() Key: CDI-482 URL: https://issues.jboss.org/browse/CDI-482 Project: CDI Specification Issues Issue Type: Feature Request Components: Events, Portable Extensions Affects Versions: 1.2.Final Reporter: Jozef Hartinger Fix For: 2.0 (discussion) Resurrecting the old proposal (CDI-36) that was rejected due to backward compatibility (CDI-281). In the meantime, alternative approach of obtaining event qualifiers (doing a programmatic lookup for EventMetadata) became available. Now that default methods are available in Java, we should consider making EventMetadata easier to use by making it part of the SPI directly: {code:JAVA} ObserverMethod.notify(T event, EventMetadata metadata) {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 11:53:02 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Wed, 24 Sep 2014 11:53:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-483) Add the AnnotatedCallable.getJavaExecutable() method In-Reply-To: References: Message-ID: Antonin Stefanutti created CDI-483: -------------------------------------- Summary: Add the AnnotatedCallable.getJavaExecutable() method Key: CDI-483 URL: https://issues.jboss.org/browse/CDI-483 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Reporter: Antonin Stefanutti -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 11:54:03 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Wed, 24 Sep 2014 11:54:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-483) Add the AnnotatedCallable.getJavaExecutable() method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated CDI-483: ----------------------------------- Description: Add the AnnotatedCallable.getJavaExecutable() method > Add the AnnotatedCallable.getJavaExecutable() method > ---------------------------------------------------- > > Key: CDI-483 > URL: https://issues.jboss.org/browse/CDI-483 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Antonin Stefanutti > > Add the AnnotatedCallable.getJavaExecutable() method -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 11:55:02 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Wed, 24 Sep 2014 11:55:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-483) Align CDI SPI with new classes in the java.lang.reflect package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated CDI-483: ----------------------------------- Summary: Align CDI SPI with new classes in the java.lang.reflect package (was: Add the AnnotatedCallable.getJavaExecutable() method) > Align CDI SPI with new classes in the java.lang.reflect package > --------------------------------------------------------------- > > Key: CDI-483 > URL: https://issues.jboss.org/browse/CDI-483 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Antonin Stefanutti > > Add the AnnotatedCallable.getJavaExecutable() method -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 11:55:02 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Wed, 24 Sep 2014 11:55:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-483) Align the CDI SPI with new classes in the java.lang.reflect package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated CDI-483: ----------------------------------- Summary: Align the CDI SPI with new classes in the java.lang.reflect package (was: Align CDI SPI with new classes in the java.lang.reflect package) > Align the CDI SPI with new classes in the java.lang.reflect package > ------------------------------------------------------------------- > > Key: CDI-483 > URL: https://issues.jboss.org/browse/CDI-483 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Antonin Stefanutti > > Add the AnnotatedCallable.getJavaExecutable() method -- This message was sent by Atlassian JIRA (v6.3.1#6329) From john.d.ament at gmail.com Wed Sep 24 11:56:04 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 24 Sep 2014 11:56:04 -0400 Subject: [cdi-dev] Binary compatibility and removing classes In-Reply-To: References: Message-ID: BTW, my point on binary compatibility is moot. As long as we don't require app developers to implement interfaces, we can add methods all over. The impls can fix that themselves. On Fri, Sep 19, 2014 at 10:10 AM, Pete Muir wrote: > > On 19 Sep 2014, at 02:31, John D. Ament wrote: > > > Hi all > > > > Was reading through the log from this past meeting. To comment on a > couple of points: > > > > - In JMS 2.0 we really wanted to remove the old Queue and Topic based > interfaces. We received a lot of push back from even deprecating them, and > the most that could be done was to add a comment to the javadoc dissuading > people from using them and only keeping them around for legacy purposes. > Similar to how @New is stuck around, probably forever, any existing classes > need to stick around forever. When it comes to pruning, the pruning is > around a technology and not just a small set of classes within a JSR. > > Agreed, this is correct, and Antoine and I are aware of this and will make > sure this is what happens. > > > > > - In JDK8, they fixed the binary compatibility issue w/ default > methods. Since CDI 2.0 should be targeting a Java 8 runtime, can we > leverage that for binary compatibility, by saying any new methods we add to > interfaces will be default methods some ambiguous/not very useful > implementation? > > Yes, if we decide to target Java 8. > > > > > John > > _______________________________________________ > > 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/20140924/1a5c257c/attachment.html From issues at jboss.org Wed Sep 24 11:58:02 2014 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Wed, 24 Sep 2014 11:58:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-483) Align the CDI SPI with new Java 8 classes in the java.lang.reflect package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated CDI-483: ----------------------------------- Summary: Align the CDI SPI with new Java 8 classes in the java.lang.reflect package (was: Align the CDI SPI with new classes in the java.lang.reflect package) > Align the CDI SPI with new Java 8 classes in the java.lang.reflect package > -------------------------------------------------------------------------- > > Key: CDI-483 > URL: https://issues.jboss.org/browse/CDI-483 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Antonin Stefanutti > > Add the AnnotatedCallable.getJavaExecutable() method -- This message was sent by Atlassian JIRA (v6.3.1#6329) From john.d.ament at gmail.com Wed Sep 24 12:57:52 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 24 Sep 2014 12:57:52 -0400 Subject: [cdi-dev] SE Features In-Reply-To: References: Message-ID: Hi all, Just to reiterate - I'd like to join the SE features workshop team and JDK8 support workshop. John On Thu, Sep 18, 2014 at 8:27 PM, John D. Ament wrote: > Hi Antoine, et. al., > > I missed this week's meeting due to some last minute scheduling issue, so > was unable to attend. I'd like to volunteer to take on the SE integration > epic/features, as well as work with Antonin on the JDK8 support. > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140924/5cee1164/attachment.html From atsticks at gmail.com Wed Sep 24 13:40:52 2014 From: atsticks at gmail.com (Anatole Tresch) Date: Wed, 24 Sep 2014 19:40:52 +0200 Subject: [cdi-dev] CDI F2F meeting In-Reply-To: References: Message-ID: ?I will not be able to join. Have fun Anatole ? 2014-09-22 12:39 GMT+02:00 Antoine Sabot-Durand : > Hi All, > > > To have a ?physical? kick off for CDI 2.0 we organised a Face to Face > meeting the 15th and 16th October. This meeting will take place in Brno Red > Hat office (in Czech Republic). All the community is invited > Red Hat will offer lunches for the 2 days and dinner on the 15th. > Transportation and hotel is note included > Agenda will include : > > - Work on the different workshop, starting with the less obvious (parts, > Contexts and SPI evolution) > - How to contribute to TCK and RI > - Start to specify new features > - Roadmap for Weld 3.0 (the CDI RI) > > We are off course open to other topics link to CDI and CDI 2.0. > > If you are interested or have question please let me know. We?ll talk > about this on the next wednesday 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. -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140924/87b10125/attachment.html From issues at jboss.org Wed Sep 24 13:52:02 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 24 Sep 2014 13:52:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-259) Add conversation begin and conversation end events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005823#comment-13005823 ] Mark Struberg commented on CDI-259: ----------------------------------- Pete, do you know if this is still needed? I think we have the same by simply observing the @Initialized(ConversationScoped.class) and injecting a Context which can then be asked for .isTransient(); So you can tell apart whether someone really did hit the Conversation#begin() or if it will end at the Request boundary > Add conversation begin and conversation end events > -------------------------------------------------- > > Key: CDI-259 > URL: https://issues.jboss.org/browse/CDI-259 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 04:56:02 2014 From: issues at jboss.org (Pete Muir (JIRA)) Date: Thu, 25 Sep 2014 04:56:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-259) Add conversation begin and conversation end events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005967#comment-13005967 ] Pete Muir commented on CDI-259: ------------------------------- Agreed that there are a number of ways to do this today. Might still want the ease of use of this approach? > Add conversation begin and conversation end events > -------------------------------------------------- > > Key: CDI-259 > URL: https://issues.jboss.org/browse/CDI-259 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 08:28:02 2014 From: issues at jboss.org (Mark Paluch (JIRA)) Date: Thu, 25 Sep 2014 08:28:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-270) Allow @WithAnnotations to be applied to other events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006065#comment-13006065 ] Mark Paluch commented on CDI-270: --------------------------------- [~pmuir] Are you talking about a scenario like the following? Extension 1: {{@Observes}} {{@WithAnnotations(@SomeAnnotation)}} (receives no event since there are no matching beans) Extension 2: {{@Observes}} PAT - adds {{@SomeAnnotation}} to the type Extension 1: {{@Observes}} {{@WithAnnotations(@SomeAnnotation)}} receives an event > Allow @WithAnnotations to be applied to other events > ---------------------------------------------------- > > Key: CDI-270 > URL: https://issues.jboss.org/browse/CDI-270 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Labels: with-annotations > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antoine at sabot-durand.net Fri Sep 26 03:32:44 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 26 Sep 2014 09:32:44 +0200 Subject: [cdi-dev] Rights on Workshop docs Message-ID: <219639BF-B44C-4DBE-A3B1-D3F08202363C@sabot-durand.net> Hi all, As I had a lot of questions regarding these rights so let me go back on this point. The only concern I have is to avoid anonymous contribution. As Google doesn?t provide a way to give right to "anyone signed in? I had to put the doc in read only by default. I also wanted to have someone in charge for each workshop (i.e someone writing a proposal). I gave edit rights to these persons. These persons in charge are free to give edit rights to other (i.e. they organise their work as they want). Some of them will prefer give comment right to avoid text erasing, it?s up to them. When you need to get right to a doc, the best way is too connect and request it from google so the persons receiving the request will have your google id. Antoine From issues at jboss.org Sat Sep 27 07:17:03 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Sat, 27 Sep 2014 07:17:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-270) Allow @WithAnnotations to be applied to other events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006675#comment-13006675 ] Mark Struberg commented on CDI-270: ----------------------------------- We should go through all the events and check whether it proves to be useful. We had a discussion about it in the events workshop and for @ProcessObserverMethod it doesn't make sense for example. > Allow @WithAnnotations to be applied to other events > ---------------------------------------------------- > > Key: CDI-270 > URL: https://issues.jboss.org/browse/CDI-270 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Labels: with-annotations > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antoine at sabot-durand.net Mon Sep 29 13:12:31 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 29 Sep 2014 10:12:31 -0700 Subject: [cdi-dev] CDI meeting and work session during Java One In-Reply-To: References: Message-ID: <495A56D7-9B89-40DC-A805-EE083483C9EC@sabot-durand.net> Guys, Finally I won?t be able to make it on thursday. I have family issue forcing me to go back to france sooner (wednesday). I you want to meet anyway tell me otherwise I will cancel the slot with Heather. Sorry, Antoine > Le 23 sept. 2014 ? 22:32, Anatole Tresch a ?crit : > > Hi Antoine > > I will join, Thursday sounds good. > > Anatole > > > 2014-09-22 20:58 GMT+02:00 Antoine Sabot-Durand >: > Hi all, > > We can have a room for a CDI meeting during Java One. It should be on Thursday the whole day or half day. Who will be there and is interested ? > > 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. > > > > -- > Anatole Tresch > Java Engineer & Architect, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > Switzerland, Europe Zurich, GMT+1 > Twitter: @atsticks > Blogs: http://javaremarkables.blogspot.ch/ > Google: atsticks > Mobile +41-76 344 62 79 > _______________________________________________ > 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/20140929/d0581ebe/attachment.html From john.d.ament at gmail.com Mon Sep 29 15:51:11 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 29 Sep 2014 12:51:11 -0700 Subject: [cdi-dev] CDI meeting and work session during Java One In-Reply-To: <495A56D7-9B89-40DC-A805-EE083483C9EC@sabot-durand.net> References: <495A56D7-9B89-40DC-A805-EE083483C9EC@sabot-durand.net> Message-ID: Hi Antoine Sorry to hear it! Presently, I'm at J1 but not involved in any CDI workshops. So it's no benefit to me currently. John On Mon, Sep 29, 2014 at 10:12 AM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Guys, > > Finally I won?t be able to make it on thursday. I have family issue > forcing me to go back to france sooner (wednesday). I you want to meet > anyway tell me otherwise I will cancel the slot with Heather. > > Sorry, > > Antoine > > > Le 23 sept. 2014 ? 22:32, Anatole Tresch a ?crit : > > Hi Antoine > > I will join, Thursday sounds good. > > Anatole > > > 2014-09-22 20:58 GMT+02:00 Antoine Sabot-Durand > : > >> Hi all, >> >> We can have a room for a CDI meeting during Java One. It should be on >> Thursday the whole day or half day. Who will be there and is interested ? >> >> 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. >> > > > > -- > *Anatole Tresch* > Java Engineer & Architect, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > * > > *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* > _______________________________________________ > 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/20140929/8a763de9/attachment-0001.html From antoine at sabot-durand.net Mon Sep 29 19:41:49 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 29 Sep 2014 16:41:49 -0700 Subject: [cdi-dev] Cancelling Wednesday meeting Message-ID: Hi guys, I have to cancel next meeting because I?ll be in a plane leaving Java One. Next meeting will be on oct 8th at 4:00pm UTC. Antoine