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(a)gmail.com&gt;: > Jens/all, > > A sort of "staging" already was possible using CDI earlier, see examples > like this: > > http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-pr... > > 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(a)lists.jboss.org&gt; wrote: > >> Send cdi-dev mailing list submissions to >> cdi-dev(a)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(a)lists.jboss.org >> >> You can reach the person managing the list at >> cdi-dev-owner(a)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 <jens.schumann(a)openknowledge.de&gt; >> Subject: Re: [cdi-dev] With the end of Java Config... >> To: Anatole Tresch <atsticks(a)gmail.com&gt;, Antonio Goncalves >> <antonio.goncalves(a)gmail.com&gt; >> Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >> Message-ID: <D02FDD99.396B9%jens.schumann(a)openknowledge.de&gt; >> 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... >> [2] >> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master... >> >> Von: Anatole Tresch <atsticks@gmail.com<mailto:atsticks@gmail.com>> >> Datum: Friday 5 September 2014 21:22 >> An: Antonio Goncalves <antonio.goncalves(a)gmail.com&lt;mailto: >> antonio.goncalves(a)gmail.com&gt;&gt; >> Cc: CDI-Dev <cdi-dev@lists.jboss.org<mailto:cdi-dev@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<Map<String,String>>. 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<MapString,String>> >> * 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@gmail.com<mailto:antonio.goncalves@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@sabot-durand.net<mailto:antoine@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-... >> ). >> 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@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.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<http://www.antoniogoncalves.org> | Twitter< >> http://twitter.com/agoncal> | LinkedIn< >> http://www.linkedin.com/in/agoncal> | Pluralsight< >> http://pluralsight.com/training/Authors/Details/antonio-goncalves> | >> Paris JUG<http://www.parisjug.org> | Devoxx France<http://www.devoxx.fr> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.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/at... >> >> ------------------------------ >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

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(a)gmail.com&gt; 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(a)gmail.com&gt; > 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(a)gmail.com&gt;: >> >>> Jens/all, >>> >>> A sort of "staging" already was possible using CDI earlier, see >>> examples like this: >>> >>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-pr... >>> >>> 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(a)lists.jboss.org&gt; >>> wrote: >>> >>>> Send cdi-dev mailing list submissions to >>>> cdi-dev(a)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(a)lists.jboss.org >>>> >>>> You can reach the person managing the list at >>>> cdi-dev-owner(a)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 <jens.schumann(a)openknowledge.de&gt; >>>> Subject: Re: [cdi-dev] With the end of Java Config... >>>> To: Anatole Tresch <atsticks(a)gmail.com&gt;, Antonio Goncalves >>>> <antonio.goncalves(a)gmail.com&gt; >>>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >>>> Message-ID: <D02FDD99.396B9%jens.schumann(a)openknowledge.de&gt; >>>> 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... >>>> [2] >>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master... >>>> >>>> Von: Anatole Tresch <atsticks@gmail.com<mailto:atsticks@gmail.com>> >>>> Datum: Friday 5 September 2014 21:22 >>>> An: Antonio Goncalves <antonio.goncalves(a)gmail.com&lt;mailto: >>>> antonio.goncalves(a)gmail.com&gt;&gt; >>>> Cc: CDI-Dev <cdi-dev@lists.jboss.org<mailto:cdi-dev@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<Map<String,String>>. 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<MapString,String>> >>>> * 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@gmail.com<mailto:antonio.goncalves@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@sabot-durand.net<mailto:antoine@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-... >>>> ). >>>> 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@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses >>>> the code under the Apache License, Version 2 ( >>>> http://www.apache.org/licenses/LICENSE-2.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<http://www.antoniogoncalves.org> | Twitter< >>>> http://twitter.com/agoncal> | LinkedIn< >>>> http://www.linkedin.com/in/agoncal> | Pluralsight< >>>> http://pluralsight.com/training/Authors/Details/antonio-goncalves> | >>>> Paris JUG<http://www.parisjug.org> | Devoxx France< >>>> http://www.devoxx.fr> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses >>>> the code under the Apache License, Version 2 ( >>>> http://www.apache.org/licenses/LICENSE-2.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/at... >>>> >>>> ------------------------------ >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses >>>> the code under the Apache License, Version 2 ( >>>> http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.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/ >> <http://javaremarkables.blogspot.ch/>* >> >> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > >

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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt;: >> >>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(a)lists.jboss.org&gt; wrote: >>> >>>Send cdi-dev mailing list submissions to >>>> cdi-dev(a)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(a)lists.jboss.org >>>> >>>>You can reach the person managing the list at >>>> cdi-dev-owner(a)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 <jens.schumann(a)openknowledge.de&gt; >>>>Subject: Re: [cdi-dev] With the end of Java Config... >>>>To: Anatole Tresch <atsticks(a)gmail.com&gt;, Antonio Goncalves >>>> <antonio.goncalves(a)gmail.com&gt; >>>>Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >>>>Message-ID: <D02FDD99.396B9%jens.schumann(a)openknowledge.de&gt; >>>>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... >>>>[2] https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master... >>>> >>>> Von: Anatole Tresch <atsticks@gmail.com<mailto:atsticks@gmail.com>> >>>>Datum: Friday 5 September 2014 21:22 >>>> An: Antonio Goncalves <antonio.goncalves@gmail.com<mailto:antonio.goncalves@gmail.com>> >>>>Cc: CDI-Dev <cdi-dev@lists.jboss.org<mailto:cdi-dev@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<Map<String,String>>. 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<MapString,String>> >>>> * 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@gmail.com<mailto:antonio.goncalves@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@sabot-durand.net<mailto:antoine@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-...). >>>>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@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> >>>>https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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<http://www.antoniogoncalves.org> | Twitter<http://twitter.com/agoncal> | LinkedIn<http://www.linkedin.com/in/agoncal> | Pluralsight<http://pluralsight.com/training/Authors/Details/antonio-go... | Paris JUG<http://www.parisjug.org> | Devoxx France<http://www.devoxx.fr> >>>> >>>>_______________________________________________ >>>>cdi-dev mailing list >>>>cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> >>>>https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/at... >>>> >>>>------------------------------ >>>> >>>>_______________________________________________ >>>>cdi-dev mailing list &gt;&gt;&gt;&gt;cdi-dev(a)lists.jboss.org >>>>https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 &gt;&gt;&gt;cdi-dev(a)lists.jboss.org >>>https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 &gt;&gt;cdi-dev(a)lists.jboss.org >>https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt;: Jens/all, A sort of "staging" already was possible using CDI earlier, see examples like this: http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-pr... 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(a)lists.jboss.org&gt; wrote: Send cdi-dev mailing list submissions to cdi-dev(a)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(a)lists.jboss.org You can reach the person managing the list at cdi-dev-owner(a)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 <jens.schumann(a)openknowledge.de&gt; Subject: Re: [cdi-dev] With the end of Java Config... To: Anatole Tresch <atsticks(a)gmail.com&gt;, Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Message-ID: <D02FDD99.396B9%jens.schumann(a)openknowledge.de&gt; 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... [2] https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master... Von: Anatole Tresch <atsticks@gmail.com<mailto:atsticks@gmail.com>> Datum: Friday 5 September 2014 21:22 An: Antonio Goncalves <antonio.goncalves(a)gmail.com&lt;mailto: antonio.goncalves(a)gmail.com&gt;&gt; Cc: CDI-Dev <cdi-dev@lists.jboss.org<mailto:cdi-dev@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<Map<String,String>>. 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<MapString,String>> * 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(a)gmail.com <mailto:antonio.goncalves@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@sabot-durand.net<mailto:antoine@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-... ). 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@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.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<http://www.antoniogoncalves.org> | Twitter< http://twitter.com/agoncal> | LinkedIn<http://www.linkedin.com/in/agoncal> | Pluralsight< http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG<http://www.parisjug.org> | Devoxx France<http://www.devoxx.fr> _______________________________________________ cdi-dev mailing list cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.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/at... ------------------------------ _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.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/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79* _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

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(a)gmail.com&gt; 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: <session-config> <cookie-config> <secure>${http.cookies.secure:false}</secure> ... 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 <struberg(a)yahoo.de&gt; 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 <werner.keil(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt;: Jens/all, A sort of "staging" already was possible using CDI earlier, see examples like this: http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-pr... 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(a)lists.jboss.org&gt; wrote: Send cdi-dev mailing list submissions to cdi-dev(a)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(a)lists.jboss.org You can reach the person managing the list at cdi-dev-owner(a)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 <jens.schumann(a)openknowledge.de&gt; Subject: Re: [cdi-dev] With the end of Java Config... To: Anatole Tresch <atsticks(a)gmail.com&gt;, Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Message-ID: <D02FDD99.396B9%jens.schumann(a)openknowledge.de&gt; 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... [2] https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master... Von: Anatole Tresch <atsticks@gmail.com<mailto:atsticks@gmail.com>> Datum: Friday 5 September 2014 21:22 An: Antonio Goncalves <antonio.goncalves(a)gmail.com&lt;mailto: antonio.goncalves(a)gmail.com&gt;&gt; Cc: CDI-Dev <cdi-dev@lists.jboss.org<mailto:cdi-dev@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<Map<String,String>>. 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<MapString,String>> * 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(a)gmail.com <mailto:antonio.goncalves@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@sabot-durand.net<mailto:antoine@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-... ). 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@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.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<http://www.antoniogoncalves.org> | Twitter< http://twitter.com/agoncal> | LinkedIn<http://www.linkedin.com/in/agoncal> | Pluralsight< http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG<http://www.parisjug.org> | Devoxx France<http://www.devoxx.fr> _______________________________________________ cdi-dev mailing list cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.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/at... ------------------------------ _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.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/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79* _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

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 <struberg(a)yahoo.de&gt;: > 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(a)gmail.com&gt; > 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(a)gmail.com&gt; > 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(a)gmail.com&gt; > 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(a)gmail.com&gt;: > > Jens/all, > > A sort of "staging" already was possible using CDI earlier, see examples > like this: > > http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-pr... > > 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(a)lists.jboss.org&gt; wrote: > > Send cdi-dev mailing list submissions to > cdi-dev(a)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(a)lists.jboss.org > > You can reach the person managing the list at > cdi-dev-owner(a)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 <jens.schumann(a)openknowledge.de&gt; > Subject: Re: [cdi-dev] With the end of Java Config... > To: Anatole Tresch <atsticks(a)gmail.com&gt;, Antonio Goncalves > <antonio.goncalves(a)gmail.com&gt; > Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; > Message-ID: <D02FDD99.396B9%jens.schumann(a)openknowledge.de&gt; > 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... > [2] > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master... > > Von: Anatole Tresch <atsticks@gmail.com<mailto:atsticks@gmail.com>> > Datum: Friday 5 September 2014 21:22 > An: Antonio Goncalves <antonio.goncalves(a)gmail.com&lt;mailto: > antonio.goncalves(a)gmail.com&gt;&gt; > Cc: CDI-Dev <cdi-dev@lists.jboss.org<mailto:cdi-dev@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<Map<String,String>>. 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<MapString,String>> > * 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(a)gmail.com > <mailto:antonio.goncalves@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@sabot-durand.net<mailto:antoine@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-... > ). > 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@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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<http://www.antoniogoncalves.org> | Twitter< > http://twitter.com/agoncal> | LinkedIn<http://www.linkedin.com/in/agoncal> > | Pluralsight< > http://pluralsight.com/training/Authors/Details/antonio-goncalves> | > Paris JUG<http://www.parisjug.org> | Devoxx France<http://www.devoxx.fr> > > _______________________________________________ > cdi-dev mailing list > cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/at... > > ------------------------------ > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/ > <http://javaremarkables.blogspot.ch/>* > > *Google: atsticksMobile +41-76 344 62 79* > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*

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(a)gmail.com&gt; 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 <atsticks(a)gmail.com&gt; > 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 <struberg(a)yahoo.de&gt;: >> >>> 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(a)gmail.com&gt; 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(a)gmail.com&gt; >>> 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(a)gmail.com&gt; >>> 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(a)gmail.com&gt;: >>> >>> Jens/all, >>> >>> A sort of "staging" already was possible using CDI earlier, see >>> examples like this: >>> >>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-pr... >>> >>> 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(a)lists.jboss.org&gt; >>> wrote: >>> >>> Send cdi-dev mailing list submissions to >>> cdi-dev(a)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(a)lists.jboss.org >>> >>> You can reach the person managing the list at >>> cdi-dev-owner(a)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 <jens.schumann(a)openknowledge.de&gt; >>> Subject: Re: [cdi-dev] With the end of Java Config... >>> To: Anatole Tresch <atsticks(a)gmail.com&gt;, Antonio Goncalves >>> <antonio.goncalves(a)gmail.com&gt; >>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >>> Message-ID: <D02FDD99.396B9%jens.schumann(a)openknowledge.de&gt; >>> 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... >>> [2] >>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master... >>> >>> Von: Anatole Tresch <atsticks@gmail.com<mailto:atsticks@gmail.com>> >>> Datum: Friday 5 September 2014 21:22 >>> An: Antonio Goncalves <antonio.goncalves(a)gmail.com&lt;mailto: >>> antonio.goncalves(a)gmail.com&gt;&gt; >>> Cc: CDI-Dev <cdi-dev@lists.jboss.org<mailto:cdi-dev@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<Map<String,String>>. 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<MapString,String>> >>> * 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@gmail.com<mailto:antonio.goncalves@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@sabot-durand.net<mailto:antoine@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-... >>> ). >>> 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@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.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<http://www.antoniogoncalves.org> | Twitter< >>> http://twitter.com/agoncal> | LinkedIn< >>> http://www.linkedin.com/in/agoncal> | Pluralsight< >>> http://pluralsight.com/training/Authors/Details/antonio-goncalves> | >>> Paris JUG<http://www.parisjug.org> | Devoxx France<http://www.devoxx.fr >>> > >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.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/at... >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.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/ >>> <http://javaremarkables.blogspot.ch/>* >>> >>> *Google: atsticksMobile +41-76 344 62 79* >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.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/ >> <http://javaremarkables.blogspot.ch/>* >> >> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* >> > >

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 <rmannibucau(a)gmail.com&gt;: > 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 <rmannibucau(a)gmail.com&gt;: > 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 <werner.keil(a)gmail.com&gt;: > > 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(a)gmail.com&gt; > 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 <werner.keil(a)gmail.com&gt;: > >>> > >>> 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(a)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 <atsticks(a)gmail.com&gt; > >>>> 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 <struberg(a)yahoo.de&gt;: > >>>>>> > >>>>>> 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(a)gmail.com&gt; 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(a)gmail.com&gt; > >>>>>> 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(a)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 <werner.keil(a)gmail.com&gt;: > >>>>>> > >>>>>> Jens/all, > >>>>>> > >>>>>> A sort of "staging" already was possible using CDI earlier, see > >>>>>> examples like this: > >>>>>> > >>>>>> > http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-pr... > >>>>>> > >>>>>> 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(a)lists.jboss.org&gt; > >>>>>> wrote: > >>>>>> > >>>>>> Send cdi-dev mailing list submissions to > >>>>>> cdi-dev(a)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(a)lists.jboss.org > >>>>>> > >>>>>> You can reach the person managing the list at > >>>>>> cdi-dev-owner(a)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 <jens.schumann(a)openknowledge.de&gt; > >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... > >>>>>> To: Anatole Tresch <atsticks(a)gmail.com&gt;, Antonio Goncalves > >>>>>> <antonio.goncalves(a)gmail.com&gt; > >>>>>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; > >>>>>> Message-ID: <D02FDD99.396B9%jens.schumann(a)openknowledge.de&gt; > >>>>>> 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... > >>>>>> [2] > >>>>>> > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master... > >>>>>> > >>>>>> Von: Anatole Tresch <atsticks@gmail.com<mailto:atsticks@gmail.com > >> > >>>>>> Datum: Friday 5 September 2014 21:22 > >>>>>> An: Antonio Goncalves > >>>>>> <antonio.goncalves@gmail.com<mailto:antonio.goncalves@gmail.com>> > >>>>>> Cc: CDI-Dev <cdi-dev(a)lists.jboss.org&lt;mailto: > cdi-dev(a)lists.jboss.org&gt;&gt; > >>>>>> 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<Map<String,String>>. 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<MapString,String>> > >>>>>> * 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@gmail.com<mailto:antonio.goncalves@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@sabot-durand.net<mailto:antoine@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-... > ). > >>>>>> 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@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> > >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>>> > >>>>>> Note that for all code provided on this list, the provider licenses > >>>>>> the code under the Apache License, Version 2 > >>>>>> (http://www.apache.org/licenses/LICENSE-2.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<http://www.antoniogoncalves.org> | > >>>>>> Twitter<http://twitter.com/agoncal> | > >>>>>> LinkedIn<http://www.linkedin.com/in/agoncal> | > >>>>>> Pluralsight< > http://pluralsight.com/training/Authors/Details/antonio-goncalves> > >>>>>> | Paris JUG<http://www.parisjug.org> | Devoxx France< > http://www.devoxx.fr> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> cdi-dev mailing list > >>>>>> cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> > >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>>> > >>>>>> Note that for all code provided on this list, the provider licenses > >>>>>> the code under the Apache License, Version 2 > >>>>>> (http://www.apache.org/licenses/LICENSE-2.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/at... > >>>>>> > >>>>>> ------------------------------ > >>>>>> > >>>>>> _______________________________________________ > >>>>>> cdi-dev mailing list > >>>>>> cdi-dev(a)lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>>> > >>>>>> Note that for all code provided on this list, the provider licenses > >>>>>> the code under the Apache License, Version 2 > >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>>> > >>>>>> Note that for all code provided on this list, the provider licenses > >>>>>> the code under the Apache License, Version 2 > >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>>> > >>>>>> Note that for all code provided on this list, the provider licenses > >>>>>> the code under the Apache License, Version 2 > >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>>> > >>>>>> Note that for all code provided on this list, the provider licenses > >>>>>> the code under the Apache License, Version 2 > >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>>> > >>>>>> Note that for all code provided on this list, the provider licenses > >>>>>> the code under the Apache License, Version 2 > >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code > > under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.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/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79*

:

:

:

:

:

:

:

:

@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 <werner.keil(a)gmail.com&gt;: > 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" > <antonio.goncalves(a)gmail.com&gt;: > >> 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(a)gmail.com&gt; >> 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" <atsticks(a)gmail.com&gt; 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 <rmannibucau(a)gmail.com&gt;: >>>>> >>>>> 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 <rmannibucau(a)gmail.com&gt;: >>>>> >>>>> 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 <werner.keil(a)gmail.com&gt;: >>>>> > 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(a)gmail.com&gt; >>>>> > 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 <werner.keil(a)gmail.com&gt;: >>>>> >>> >>>>> >>> 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(a)gmail.com&gt; >>>>> >>> 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 >>>>> >>>> <atsticks(a)gmail.com&gt; >>>>> >>>> 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 <struberg(a)yahoo.de&gt;: >>>>> >>>>>> >>>>> >>>>>> 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(a)gmail.com&gt; 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(a)gmail.com&gt; >>>>> >>>>>> 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(a)gmail.com&gt; >>>>> >>>>>> 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(a)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-pr... >>>>> >>>>>> >>>>> >>>>>> 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(a)lists.jboss.org&gt; >>>>> >>>>>> wrote: >>>>> >>>>>> >>>>> >>>>>> Send cdi-dev mailing list submissions to >>>>> >>>>>> cdi-dev(a)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(a)lists.jboss.org >>>>> >>>>>> >>>>> >>>>>> You can reach the person managing the list at >>>>> >>>>>> cdi-dev-owner(a)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 <jens.schumann(a)openknowledge.de&gt; >>>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... >>>>> >>>>>> To: Anatole Tresch <atsticks(a)gmail.com&gt;, Antonio Goncalves >>>>> >>>>>> <antonio.goncalves(a)gmail.com&gt; >>>>> >>>>>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >>>>> >>>>>> Message-ID: <D02FDD99.396B9%jens.schumann(a)openknowledge.de&gt; >>>>> >>>>>> 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... >>>>> >>>>>> [2] >>>>> >>>>>> >>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master... >>>>> >>>>>> >>>>> >>>>>> Von: Anatole Tresch >>>>> >>>>>> <atsticks@gmail.com<mailto:atsticks@gmail.com>> >>>>> >>>>>> Datum: Friday 5 September 2014 21:22 >>>>> >>>>>> An: Antonio Goncalves >>>>> >>>>>> >>>>> >>>>>> <antonio.goncalves(a)gmail.com&lt;mailto: antonio.goncalves(a)gmail.com&gt;&gt; >>>>> >>>>>> Cc: CDI-Dev >>>>> >>>>>> <cdi-dev@lists.jboss.org<mailto:cdi-dev@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<Map<String,String>>. 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<MapString,String>> >>>>> >>>>>> * 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(a)gmail.com&lt;mailto: antonio.goncalves(a)gmail.com&gt;&gt;: >>>>> >>>>>> 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@sabot-durand.net<mailto:antoine@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-... ). >>>>> >>>>>> 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@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>>> >>>>> >>>>>> Note that for all code provided on this list, the provider >>>>> >>>>>> licenses >>>>> >>>>>> the code under the Apache License, Version 2 >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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<http://www.antoniogoncalves.org> | >>>>> >>>>>> Twitter<http://twitter.com/agoncal> | >>>>> >>>>>> LinkedIn<http://www.linkedin.com/in/agoncal> | >>>>> >>>>>> >>>>> >>>>>> Pluralsight< http://pluralsight.com/training/Authors/Details/antonio-goncalves> >>>>> >>>>>> | Paris JUG<http://www.parisjug.org> | Devoxx >>>>> >>>>>> France<http://www.devoxx.fr> >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> cdi-dev mailing list >>>>> >>>>>> cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>>> >>>>> >>>>>> Note that for all code provided on this list, the provider >>>>> >>>>>> licenses >>>>> >>>>>> the code under the Apache License, Version 2 >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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/at... >>>>> >>>>>> >>>>> >>>>>> ------------------------------ >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> cdi-dev mailing list >>>>> >>>>>> cdi-dev(a)lists.jboss.org >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>>> >>>>> >>>>>> Note that for all code provided on this list, the provider >>>>> >>>>>> licenses >>>>> >>>>>> the code under the Apache License, Version 2 >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>>> >>>>> >>>>>> Note that for all code provided on this list, the provider >>>>> >>>>>> licenses >>>>> >>>>>> the code under the Apache License, Version 2 >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>>> >>>>> >>>>>> Note that for all code provided on this list, the provider >>>>> >>>>>> licenses >>>>> >>>>>> the code under the Apache License, Version 2 >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>>> >>>>> >>>>>> Note that for all code provided on this list, the provider >>>>> >>>>>> licenses >>>>> >>>>>> the code under the Apache License, Version 2 >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>>> >>>>> >>>>>> Note that for all code provided on this list, the provider >>>>> >>>>>> licenses >>>>> >>>>>> the code under the Apache License, Version 2 >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org >>>>> > https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> > >>>>> > Note that for all code provided on this list, the provider licenses >>>>> > the code >>>>> > under the Apache License, Version 2 >>>>> > (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.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

On 8 Sep 2014, at 11:06, Werner Keil <werner.keil(a)gmail.com&gt; 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(a)gmail.com&gt; 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 <werner.keil(a)gmail.com&gt;: > > 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" > > <antonio.goncalves(a)gmail.com&gt;: > > > >> 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(a)gmail.com&gt; > >> 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" <atsticks(a)gmail.com&gt; 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 <rmannibucau(a)gmail.com >: > >>>>> > >>>>> 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 <rmannibucau(a)gmail.com >: > >>>>> > >>>>> 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 <werner.keil(a)gmail.com&gt;: > >>>>> > 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(a)gmail.com&gt; > >>>>> > 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 <werner.keil(a)gmail.com&gt;: > >>>>> >>> > >>>>> >>> 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(a)gmail.com&gt; > >>>>> >>> 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 > >>>>> >>>> <atsticks(a)gmail.com&gt; > >>>>> >>>> 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 <struberg(a)yahoo.de >: > >>>>> >>>>>> > >>>>> >>>>>> 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(a)gmail.com&gt; 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(a)gmail.com&gt; > >>>>> >>>>>> 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(a)gmail.com&gt; > >>>>> >>>>>> 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(a)gmail.com&gt;: > >>>>> >>>>>> > >>>>> >>>>>> Jens/all, > >>>>> >>>>>> > >>>>> >>>>>> A sort of "staging" already was possible using CDI earlier, see > >>>>> >>>>>> examples like this: > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-pr... > >>>>> >>>>>> > >>>>> >>>>>> 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(a)lists.jboss.org&gt; > >>>>> >>>>>> wrote: > >>>>> >>>>>> > >>>>> >>>>>> Send cdi-dev mailing list submissions to > >>>>> >>>>>> cdi-dev(a)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(a)lists.jboss.org > >>>>> >>>>>> > >>>>> >>>>>> You can reach the person managing the list at > >>>>> >>>>>> cdi-dev-owner(a)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 <jens.schumann(a)openknowledge.de&gt; > >>>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... > >>>>> >>>>>> To: Anatole Tresch <atsticks(a)gmail.com&gt;, Antonio Goncalves > >>>>> >>>>>> <antonio.goncalves(a)gmail.com&gt; > >>>>> >>>>>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; > >>>>> >>>>>> Message-ID: <D02FDD99.396B9%jens.schumann(a)openknowledge.de&gt; > >>>>> >>>>>> 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... > >>>>> >>>>>> [2] > >>>>> >>>>>> > >>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master... > >>>>> >>>>>> > >>>>> >>>>>> Von: Anatole Tresch > >>>>> >>>>>> <atsticks@gmail.com<mailto:atsticks@gmail.com>> > >>>>> >>>>>> Datum: Friday 5 September 2014 21:22 > >>>>> >>>>>> An: Antonio Goncalves > >>>>> >>>>>> > >>>>> >>>>>> <antonio.goncalves(a)gmail.com&lt;mailto: antonio.goncalves(a)gmail.com&gt;&gt; > >>>>> >>>>>> Cc: CDI-Dev > >>>>> >>>>>> <cdi-dev@lists.jboss.org<mailto:cdi-dev@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<Map<String,String>>. 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<MapString,String>> > >>>>> >>>>>> * 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(a)gmail.com&lt;mailto: antonio.goncalves(a)gmail.com&gt;&gt;: > >>>>> >>>>>> 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@sabot-durand.net<mailto:antoine@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-... ). > >>>>> >>>>>> 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@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> > >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> >>>>>> > >>>>> >>>>>> Note that for all code provided on this list, the provider > >>>>> >>>>>> licenses > >>>>> >>>>>> the code under the Apache License, Version 2 > >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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<http://www.antoniogoncalves.org> | > >>>>> >>>>>> Twitter<http://twitter.com/agoncal> | > >>>>> >>>>>> LinkedIn<http://www.linkedin.com/in/agoncal> | > >>>>> >>>>>> > >>>>> >>>>>> Pluralsight< http://pluralsight.com/training/Authors/Details/antonio-goncalves> > >>>>> >>>>>> | Paris JUG<http://www.parisjug.org> | Devoxx > >>>>> >>>>>> France<http://www.devoxx.fr> > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> cdi-dev mailing list > >>>>> >>>>>> cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> > >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> >>>>>> > >>>>> >>>>>> Note that for all code provided on this list, the provider > >>>>> >>>>>> licenses > >>>>> >>>>>> the code under the Apache License, Version 2 > >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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/at... > >>>>> >>>>>> > >>>>> >>>>>> ------------------------------ > >>>>> >>>>>> > >>>>> >>>>>> _______________________________________________ > >>>>> >>>>>> cdi-dev mailing list > >>>>> >>>>>> cdi-dev(a)lists.jboss.org > >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> >>>>>> > >>>>> >>>>>> Note that for all code provided on this list, the provider > >>>>> >>>>>> licenses > >>>>> >>>>>> the code under the Apache License, Version 2 > >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> >>>>>> > >>>>> >>>>>> Note that for all code provided on this list, the provider > >>>>> >>>>>> licenses > >>>>> >>>>>> the code under the Apache License, Version 2 > >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> >>>>>> > >>>>> >>>>>> Note that for all code provided on this list, the provider > >>>>> >>>>>> licenses > >>>>> >>>>>> the code under the Apache License, Version 2 > >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> >>>>>> > >>>>> >>>>>> Note that for all code provided on this list, the provider > >>>>> >>>>>> licenses > >>>>> >>>>>> the code under the Apache License, Version 2 > >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> >>>>>> > >>>>> >>>>>> Note that for all code provided on this list, the provider > >>>>> >>>>>> licenses > >>>>> >>>>>> the code under the Apache License, Version 2 > >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > >>>>> > https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> > > >>>>> > Note that for all code provided on this list, the provider licenses > >>>>> > the code > >>>>> > under the Apache License, Version 2 > >>>>> > (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> > >>> Note that for all code provided on this list, the provider licenses the > >>> code under the Apache License, Version 2 > >>> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

Le 8 sept. 2014 à 15:31, Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; 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 <rmannibucau(a)gmail.com <mailto:rmannibucau@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/ <http://rmannibucau.wordpress.com/> LinkedIn: http://fr.linkedin.com/in/rmannibucau <http://fr.linkedin.com/in/rmannibucau> Github: https://github.com/rmannibucau <https://github.com/rmannibucau> 2014-09-08 10:29 GMT+02:00 Werner Keil <werner.keil(a)gmail.com <mailto:werner.keil@gmail.com>>: > 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" > <antonio.goncalves(a)gmail.com <mailto:antonio.goncalves@gmail.com>>: > >> 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(a)gmail.com <mailto:rmannibucau@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" <atsticks(a)gmail.com <mailto:atsticks@gmail.com>> 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 <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>>: >>>>> >>>>> 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 <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>>: >>>>> >>>>> 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/ <http://rmannibucau.wordpress.com/> >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau <http://fr.linkedin.com/in/rmannibucau> >>>>> Github: https://github.com/rmannibucau <https://github.com/rmannibucau> >>>>> >>>>> >>>>> 2014-09-07 23:39 GMT+02:00 Werner Keil <werner.keil(a)gmail.com <mailto:werner.keil@gmail.com>>: >>>>> > 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(a)gmail.com <mailto:atsticks@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 <werner.keil(a)gmail.com <mailto:werner.keil@gmail.com>>: >>>>> >>> >>>>> >>> 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(a)gmail.com <mailto:john.d.ament@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 >>>>> >>>> <atsticks(a)gmail.com <mailto:atsticks@gmail.com>> >>>>> >>>> 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 <struberg(a)yahoo.de <mailto:struberg@yahoo.de>>: >>>>> >>>>>> >>>>> >>>>>> 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(a)gmail.com <mailto:werner.keil@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 >>>>> >>>>>> <john.d.ament(a)gmail.com <mailto:john.d.ament@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 <http://deltaspike.apache.org/configuration.html> >>>>> >>>>>> >>>>> >>>>>> John >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch >>>>> >>>>>> <atsticks(a)gmail.com <mailto:atsticks@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 <werner.keil(a)gmail.com <mailto:werner.keil@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-pr... <http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-pr... >>>>> >>>>>> >>>>> >>>>>> 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(a)lists.jboss.org <mailto:cdi-dev-request@lists.jboss.org>> >>>>> >>>>>> wrote: >>>>> >>>>>> >>>>> >>>>>> Send cdi-dev mailing list submissions to >>>>> >>>>>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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(a)lists.jboss.org <mailto:cdi-dev-request@lists.jboss.org> >>>>> >>>>>> >>>>> >>>>>> You can reach the person managing the list at >>>>> >>>>>> cdi-dev-owner(a)lists.jboss.org <mailto:cdi-dev-owner@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 <jens.schumann(a)openknowledge.de <mailto:jens.schumann@openknowledge.de>> >>>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... >>>>> >>>>>> To: Anatole Tresch <atsticks(a)gmail.com <mailto:atsticks@gmail.com>>, Antonio Goncalves >>>>> >>>>>> <antonio.goncalves(a)gmail.com <mailto:antonio.goncalves@gmail.com>> >>>>> >>>>>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>> >>>>> >>>>>> Message-ID: <D02FDD99.396B9%jens.schumann(a)openknowledge.de <mailto:D02FDD99.396B9%25jens.schumann@openknowledge.de>> >>>>> >>>>>> 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 <http://cdi-spec.org/>;. >>>>> >>>>>> >>>>> >>>>>> Jens >>>>> >>>>>> [1] >>>>> >>>>>> >>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master... <https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master... >>>>> >>>>>> [2] >>>>> >>>>>> >>>>> >>>>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master... <https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master... >>>>> >>>>>> >>>>> >>>>>> Von: Anatole Tresch >>>>> >>>>>> <atsticks(a)gmail.com <mailto:atsticks@gmail.com><mailto:atsticks@gmail.com <mailto:atsticks@gmail.com>>> >>>>> >>>>>> Datum: Friday 5 September 2014 21:22 >>>>> >>>>>> An: Antonio Goncalves >>>>> >>>>>> >>>>> >>>>>> <antonio.goncalves(a)gmail.com <mailto:antonio.goncalves@gmail.com><mailto:antonio.goncalves@gmail.com <mailto:antonio.goncalves@gmail.com>>> >>>>> >>>>>> Cc: CDI-Dev >>>>> >>>>>> <cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org><mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@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<Map<String,String>>. 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<MapString,String>> >>>>> >>>>>> * 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(a)gmail.com <mailto:antonio.goncalves@gmail.com><mailto:antonio.goncalves@gmail.com <mailto:antonio.goncalves@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(a)sabot-durand.net <mailto:antoine@sabot-durand.net><mailto:antoine@sabot-durand.net <mailto:antoine@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-... <http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-...>). >>>>> >>>>>> 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 <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(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org><mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@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. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> Antonio Goncalves >>>>> >>>>>> Software architect, Java Champion and Pluralsight author >>>>> >>>>>> >>>>> >>>>>> Web site<http://www.antoniogoncalves.org <http://www.antoniogoncalves.org/>> | >>>>> >>>>>> Twitter<http://twitter.com/agoncal <http://twitter.com/agoncal>> | >>>>> >>>>>> LinkedIn<http://www.linkedin.com/in/agoncal <http://www.linkedin.com/in/agoncal>> | >>>>> >>>>>> >>>>> >>>>>> Pluralsight<http://pluralsight.com/training/Authors/Details/antonio-go... <http://pluralsight.com/training/Authors/Details/antonio-goncalves>> >>>>> >>>>>> | Paris JUG<http://www.parisjug.org <http://www.parisjug.org/>> | Devoxx >>>>> >>>>>> France<http://www.devoxx.fr <http://www.devoxx.fr/>> >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> cdi-dev mailing list >>>>> >>>>>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org><mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@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. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> 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/ <http://javaremarkables.blogspot.ch/> >>>>> >>>>>> Google: atsticks >>>>> >>>>>> Mobile +41-76 344 62 79 <tel:%2B41-76%20344%2062%2079> >>>>> >>>>>> -------------- next part -------------- >>>>> >>>>>> An HTML attachment was scrubbed... >>>>> >>>>>> URL: >>>>> >>>>>> >>>>> >>>>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/at... <http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/at... >>>>> >>>>>> >>>>> >>>>>> ------------------------------ >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> cdi-dev mailing list >>>>> >>>>>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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 20 >>>>> >>>>>> *************************************** >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> cdi-dev mailing list >>>>> >>>>>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> 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/ <http://javaremarkables.blogspot.ch/> >>>>> >>>>>> Google: atsticks >>>>> >>>>>> Mobile +41-76 344 62 79 >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> cdi-dev mailing list >>>>> >>>>>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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(a)lists.jboss.org <mailto:cdi-dev@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(a)lists.jboss.org <mailto:cdi-dev@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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> 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/ <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/ <http://javaremarkables.blogspot.ch/> >>>>> >> Google: atsticks >>>>> >> Mobile +41-76 344 62 79 >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > cdi-dev mailing list >>>>> > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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. >>>> >>>> >>>> >>>> >>>> -- >>>> 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/ <http://javaremarkables.blogspot.ch/> >>>> Google: atsticks >>>> Mobile +41-76 344 62 79 >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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. >> >> >> >> >> -- >> 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 <http://www.antoniogoncalves.org/> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>_______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.