<div dir="ltr">It&#39;s just a matter of knowing what we want to do :<div><br></div><div>* Add configuration into CDI 2.0 : it goes into the spec</div><div>* Forget about configuration : it goes nowhere</div><div>* 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 &quot;we&#39;ve deeply thought about it, this is the way we think it should be done, now the future EG decides&quot;</div><div><br></div><div>Antonio</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 8, 2014 at 11:51 AM, Romain Manni-Bucau <span dir="ltr">&lt;<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">@Antonio: -1 for an appendix, bean validation is the example it is<br>
broken. Idea is awesome, everybody liked it so it was added -&gt; great.<br>
Here everybody already agrees it is good so no need of &quot;staging&quot; phase<br>
IMHO. BV appendix was not the API used so it broke apps using it. SO<br>
using proprietary stuff is the same, it basically mean an appendix<br>
spec for something not under discussion (regarding its need) is IMHO<br>
useless.<br>
<span class=""><br>
<br>
Romain Manni-Bucau<br>
Twitter: @rmannibucau<br>
Blog: <a href="http://rmannibucau.wordpress.com/" target="_blank">http://rmannibucau.wordpress.com/</a><br>
LinkedIn: <a href="http://fr.linkedin.com/in/rmannibucau" target="_blank">http://fr.linkedin.com/in/rmannibucau</a><br>
Github: <a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
<br>
<br>
</span><div><div class="h5">2014-09-08 10:29 GMT+02:00 Werner Keil &lt;<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>&gt;:<br>
&gt; Hi,<br>
&gt;<br>
&gt; If it&#39;s not really usable as API or annotation I don&#39;t see much value in<br>
&gt; adding some &quot;how to&quot; or intent for the future into the Spec Document.<br>
&gt;<br>
&gt; If it was to become a part of CDI 2, there&#39;s nothing against optionality<br>
&gt; like MEEP 8 or JSR 363 already practice on the SE/EE side either.<br>
&gt;<br>
&gt; Agorava/DeltaSpike demonstrate how true modularity work, similar to the JSRs<br>
&gt; mentioned above, where you have multiple module JARs/bundles instead of a<br>
&gt; big monolithic one. Some JSRs like Batch also declared separate &quot;annotation&quot;<br>
&gt; modules, so that&#39;s what CDI 2 should also do if it was a feature Inside of<br>
&gt; it.<br>
&gt; Calling some features optional if they&#39;re not used by every implementation<br>
&gt; allows them to chose. That was also the main value of keeping @Inject a<br>
&gt; separate &quot;module&quot; under CDI. It was never included into a JDK but used<br>
&gt; independently.<br>
&gt;<br>
&gt; The core of a Config module would ideally work in SE, but CDI 2 already<br>
&gt; declared an aim to have some modules work under SE.<br>
&gt;<br>
&gt; Werner<br>
&gt;<br>
&gt; Am 08.09.2014 09:47 schrieb &quot;Antonio Goncalves&quot;<br>
&gt; &lt;<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>&gt;:<br>
&gt;<br>
&gt;&gt; Hi all,<br>
&gt;&gt;<br>
&gt;&gt; I really have some concerns about adding configuration into CDI but I can<br>
&gt;&gt; see benefits too. And what about adding it... and not adding it at the same<br>
&gt;&gt; time ? In Bean Validation 1.0, the Expert Group decided not to include<br>
&gt;&gt; method-level validation in the spec (it was included in 1.1). But what they<br>
&gt;&gt; did is to add it as a proposal in the Appendix.<br>
&gt;&gt;<br>
&gt;&gt; If we feel some configuration should get in, why not have a proposal in<br>
&gt;&gt; the Appendix of CDI 2.0  ? It could then be implemented by Weld (and<br>
&gt;&gt; OpenWebBeans if they feel like it). And then, if it&#39;s successful and things<br>
&gt;&gt; get easier, get its own JSR for Java EE 9.<br>
&gt;&gt;<br>
&gt;&gt; WDYT ?<br>
&gt;&gt;<br>
&gt;&gt; Antonio<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hmm<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I see config jsr as a jse spec which would allow EE injections in config<br>
&gt;&gt;&gt; components in EE containers (exactly like jbatch).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; This way it can be used without any container or with any container<br>
&gt;&gt;&gt; easily. Only limit will be to not do something cdi/known containers will not<br>
&gt;&gt;&gt; support I think.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Not sure EE side is needed today, a lot can already be done without it<br>
&gt;&gt;&gt; and it can be enhanced later adding some integration words.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Le 8 sept. 2014 00:01, &quot;Anatole Tresch&quot; &lt;<a href="mailto:atsticks@gmail.com">atsticks@gmail.com</a>&gt; a écrit :<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Hi Romain<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; just a few remarks inline...<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Summarizing<br>
&gt;&gt;&gt;&gt; 1) injection of values, reinjection, feedback on config changes can all<br>
&gt;&gt;&gt;&gt; be done with already existing features (producers, extensions).<br>
&gt;&gt;&gt;&gt; 2) configuring/bootstrapping CDI itself, e.g. configuration, is targeted<br>
&gt;&gt;&gt;&gt; with CDI 2.0 (see spec failing)<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; So basically we could try to look if there is enough interest to<br>
&gt;&gt;&gt;&gt; standardize configuration in a more general way. For deployment aspects we<br>
&gt;&gt;&gt;&gt; need an EE JSR, for the rest, another SE standard may be an option as<br>
&gt;&gt;&gt;&gt; well... tbd...<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; -Anatole<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>&gt;:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; well sorry to pop in so late but here are my 2cts<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; easy ;)<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
</div></div><span class="">&gt;&gt;&gt;&gt;&gt; Config JSR is more about environment config IMHO and putting it in CDI<br>
&gt;&gt;&gt;&gt;&gt; doesn&#39;t make sense since more or more spec works without any other<br>
&gt;&gt;&gt;&gt;&gt; spec - CDI in our case.<br>
&gt;&gt;&gt;&gt;<br>
</span>&gt;&gt;&gt;&gt; CDI even with some config mechanism added would still work &quot;standalone&quot;.<br>
<span class="">&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; This mean CDI can&#39;t be the place but should<br>
&gt;&gt;&gt;&gt;&gt; just be the bridge for config JSR.<br>
&gt;&gt;&gt;&gt;<br>
</span>&gt;&gt;&gt;&gt; As I suggested as well.<br>
<span class="">&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Plus CDI config will surely highly<br>
&gt;&gt;&gt;&gt;&gt; be an application config first (beans.xml should be the place then)<br>
&gt;&gt;&gt;&gt;<br>
</span>&gt;&gt;&gt;&gt; Yes, app config, but beware people of writing config into beans.xml.<br>
&gt;&gt;&gt;&gt; That is definitively in most cases not what you want. CDI should not define,<br>
&gt;&gt;&gt;&gt; where and how config is located and formatted. CDI should provide a SPI,<br>
&gt;&gt;&gt;&gt; where config providers can publish the configured values, so it can be<br>
&gt;&gt;&gt;&gt; injected wherever needed. E.g. some kind of producer, that can provide<br>
&gt;&gt;&gt;&gt; multiple objects to be injected and can benefit from some kind of callback<br>
&gt;&gt;&gt;&gt; mechanism would be sufficient...<br>
<span class="">&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; then environment config can be done at EE level (saying it has to<br>
&gt;&gt;&gt;&gt;&gt; support placeholders or any pre deployment processing).<br>
&gt;&gt;&gt;&gt;<br>
</span>&gt;&gt;&gt;&gt; Config is much more complex. There is no clear border what is<br>
&gt;&gt;&gt;&gt; environment config or environment dependent and what not. This depends on<br>
&gt;&gt;&gt;&gt; what kind of application you have deployed. As an example the email address,<br>
&gt;&gt;&gt;&gt; where you send error messages, can be different depenending on the<br>
&gt;&gt;&gt;&gt; stage/environment, but this is not EE related config entry. Also what an<br>
&gt;&gt;&gt;&gt; environment is, is not a thing that you can define completely. So I agree<br>
&gt;&gt;&gt;&gt; not to add this complexities to CDI, I would hide them between some kind of<br>
&gt;&gt;&gt;&gt; &quot;config provider&quot;, as mentioned above. CDI does not need to know if the<br>
&gt;&gt;&gt;&gt; config provided is environment dependent or not, its just what is visible at<br>
&gt;&gt;&gt;&gt; a current runtime state...<br>
<span class="">&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; If you put something like ProjectStage in CDI it is great but then you<br>
&gt;&gt;&gt;&gt;&gt; have it in JSF, CDI and finally surely all specs...same as<br>
&gt;&gt;&gt;&gt;&gt; converters...<br>
&gt;&gt;&gt;&gt;<br>
</span>&gt;&gt;&gt;&gt; That was originally the idea, when doing a EE config JSR, but without<br>
&gt;&gt;&gt;&gt; such standard. I agree, CDI is not the place to define them.<br>
<span class="">&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Config should really be split in:<br>
&gt;&gt;&gt;&gt;&gt; 1) spec dependent config -&gt; spec.xml<br>
&gt;&gt;&gt;&gt;&gt; 2) *common* config (a bit like javax.annotation) for environment and<br>
&gt;&gt;&gt;&gt;&gt; external configuration -&gt; Config JSR<br>
&gt;&gt;&gt;&gt;<br>
</span>&gt;&gt;&gt;&gt; Not 100% sure, if a get the point here...<br>
<span class="">&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>&gt;:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; well sorry to pop in so late but here are my 2cts<br>
&gt;&gt;&gt;&gt;&gt;<br>
</span><div><div class="h5">&gt;&gt;&gt;&gt;&gt; Config JSR is more about environment config IMHO and putting it in CDI<br>
&gt;&gt;&gt;&gt;&gt; doesn&#39;t make sense since more or more spec works without any other<br>
&gt;&gt;&gt;&gt;&gt; spec - CDI in our case. This mean CDI can&#39;t be the place but should<br>
&gt;&gt;&gt;&gt;&gt; just be the bridge for config JSR. Plus CDI config will surely highly<br>
&gt;&gt;&gt;&gt;&gt; be an application config first (beans.xml should be the place then)<br>
&gt;&gt;&gt;&gt;&gt; then environment config can be done at EE level (saying it has to<br>
&gt;&gt;&gt;&gt;&gt; support placeholders or any pre deployment processing).<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; If you put something like ProjectStage in CDI it is great but then you<br>
&gt;&gt;&gt;&gt;&gt; have it in JSF, CDI and finally surely all specs...same as<br>
&gt;&gt;&gt;&gt;&gt; converters...<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Config should really be split in:<br>
&gt;&gt;&gt;&gt;&gt; 1) spec dependent config -&gt; spec.xml<br>
&gt;&gt;&gt;&gt;&gt; 2) *common* config (a bit like javax.annotation) for environment and<br>
&gt;&gt;&gt;&gt;&gt; external configuration -&gt; Config JSR<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; wdyt?<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Romain Manni-Bucau<br>
&gt;&gt;&gt;&gt;&gt; Twitter: @rmannibucau<br>
&gt;&gt;&gt;&gt;&gt; Blog: <a href="http://rmannibucau.wordpress.com/" target="_blank">http://rmannibucau.wordpress.com/</a><br>
&gt;&gt;&gt;&gt;&gt; LinkedIn: <a href="http://fr.linkedin.com/in/rmannibucau" target="_blank">http://fr.linkedin.com/in/rmannibucau</a><br>
&gt;&gt;&gt;&gt;&gt; Github: <a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; 2014-09-07 23:39 GMT+02:00 Werner Keil &lt;<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>&gt;:<br>
&gt;&gt;&gt;&gt;&gt; &gt; Sounds like an argument for a CDI module rather than a separate JSR<br>
&gt;&gt;&gt;&gt;&gt; &gt; then?;-)<br>
&gt;&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt; On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch &lt;<a href="mailto:atsticks@gmail.com">atsticks@gmail.com</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; I would not worry about CDI regarding licensing. Just the sentence<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; was<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; that Oracle does not want to have more ALv2 in addition to what is<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; already<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; there. So as long as we do things within CDI, no worries, I think.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; For new<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; EE JSRs nevertheless this is a BIG issue and should be clarified by<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; the EC!<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; 2014-09-07 21:44 GMT+02:00 Werner Keil &lt;<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>&gt;:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; ALv2<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; as a dual-license, this was discussed by EC Members but both JCP EC<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; and<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; Oracle Legal/PMO seems fine with it, and CDI is already an<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; essential<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; building block to Java EE 6/7, hence used with Glassfish, too. I<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; wasn&#39;t<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; involved in these discussions, but given CDI is especially liberal<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; and fully<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; accepted by JCP formalities and license policies, I don&#39;t really<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; see what<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; the problem wss for Anatole&#39;s JSR attempt (though I know, both<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; Oracle and<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; other EC Members/companies don&#39;t always prefer this kind of<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; licensing...;-)<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; Werner<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; &lt;<a href="mailto:john.d.ament@gmail.com">john.d.ament@gmail.com</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; Ok, this mail has me more concerned than anything.  Can you<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; clarify this<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; &lt;<a href="mailto:atsticks@gmail.com">atsticks@gmail.com</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Hi All<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; unfortunately things seem quite complicated:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; first of all, similarities with Deltaspike are basically not<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; accidental. The concepts we developed in Credit Suisse are very<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; similar to<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Deltaspike, though Deltaspike was not yet born at that time.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Fortunately we<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; ended up with a similar kind of solution.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; filtering still can be done. My idea is to define some kind of<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; &quot;configuration provider&quot;, which then is dynamically asked for<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; configuration.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; How the provider is internally organized, is completely<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; transparent to CDI.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; This enables to have multi-layered, complex config solutions work<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; the same<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; (from a view point of CDI) like simple programmatic test<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; configurations<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; during unit tests. The config provider still can support<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; filtering and<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; dynamic resolution as commonly used in configuration systems.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Similarly the<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; format is basically also not fixed. Of course, would a reference<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; implementation provide a set of functionalities, but I would<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; definitively<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; not define the exact configuration mechanism as part of the CDI<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; (or even a<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; EE config JSR). Another reason, beside complexity and time, is<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; the fact that<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; different companies handle, store and manage configuration<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; differently, so a<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; mechanism must be flexible enough to accommodate these, without<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; adoption<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; rate will be low. Furthermore this flexibility also keeps doors<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; open for use<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; cases we do not know yet.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Also we have to separate some basically two types of<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; configuration<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; aspects:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; application config basically is injected into deployed<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; components, but<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; basically only can affect deployment to the extend it can be<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; managed and<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; injected by CDI. The basic architecture and design, how<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; application servers<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; to load and deploy are basically not affected. This type of<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; configuration<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; (mechanism) I see also as a possible addition to CDI, if we<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; really fail to<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; do something in another JSR. With CDI going for a more modular<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; design, even<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; basic configuration of CDI can be possible, given we have some<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; kind of API,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; we can access during CDI initialization.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; On the other side deployment configuration affects directly how<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; the<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; application server deploys the application. Configuration here<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; would allow<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; to define datasources, EJBs, transactional aspects, security,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; persistence,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; war and ear configurations etc. Basically everything you do as of<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; today with<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; some kind of XML file, or annotation. Hereby enabling more<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; flexibility into<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; the existing descriptors is relatively easy, but as mentioned by<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Mark,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; constraint. Adding more flexibility raises other subtle problems.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Imagine a<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; application module, e.g. a war, that defines everything it<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; requires. There<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; is no need to configure anything more on server side (with spring<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; you can do<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; this, with Java EE unfortunately not). But this has a severe<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; consequence, it<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; would make the application really portable in the sense, that it<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; can be<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; moved between different app servers (vendors) without any change<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; (ideally).<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; As a result commercial profits of some vendor companies may be<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; affected. I<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; think this is actually one of the key points, why things are<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; getting so<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; complicated in that area.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Legal aspects also were discussed. One of them is a possible<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; legal<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; clash of ALv2 with GPL. This is the case already within<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Glassfish, but one<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; of the reasons, why ALv2 was not acceptable to Oracle&#39;s legal<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; department. At<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; the end we decided to use a BSD model. Even dual licensing<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; BSD/ALv2 could<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; theoretically be an option. If you would choose ALv2, Oracle will<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; not<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; include your RI into Glassfish, which is the RI for the EE<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Umbrella JSR,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; meaning your JSR will not be included into EE8. So what should we<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; do? I<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; don&#39;t have a good answer...<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; So, I like to discuss configuration aspects here. Nevertheless if<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; we<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; decide to add config aspects, be aware that we might only<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; (mainly) support<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; application config, since everything else directly would impact<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; other JSRs.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; And that is obviously quite similar to what Apache Deltaspike is<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; all about<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; ;-)<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Cheers,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Anatole<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; 2014-09-07 14:46 GMT+02:00 Mark Struberg &lt;<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>&gt;:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Yes, the config group also was (obviously) looking at<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; DeltaSpikes<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; config mechanism as well.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; There were others who wanted to go more into the &#39;filtering&#39;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; approach<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; as done on WebLogic servers (though not sure who else does that<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; as well).<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; You know, having all the XML configs like WEB-INF/web.xml<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; containing<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; placeholders and the real values only get placed in there at<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; deployment<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; time. I personally find this approach a bit limited from a<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; technical<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; perspective and it already didn&#39;t work out for me when using<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; WebLogic (what<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; about changing a configured value after the deployment was done?<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; What about<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; security? Having passwords in web.xml, unit testing, ...).<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; There are of course also other approaches which all might have<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; strong<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; sides and would have needed to get discussed.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; But utterly the problem seems to have been legal reasons. We<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; even<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; offered to have Anatole/CS lead the EG and do the RI as an ASF<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; project with<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; substantial support and participation from the JBoss, DeltaSpike<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; and TomEE<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; communities.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Anyway, the time will come when we will resurrect this effort.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; LieGrue,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; strub<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; On Sunday, 7 September 2014, 14:29, Werner Keil<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Yep, it contains a simple but extendable notion of ProjectStage,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; too;-)<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:john.d.ament@gmail.com">john.d.ament@gmail.com</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Anatole,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; I&#39;m wondering if some of your configuration description falls<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; under<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; what was put together in DeltaSpike?<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="http://deltaspike.apache.org/configuration.html" target="_blank">http://deltaspike.apache.org/configuration.html</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; John<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:atsticks@gmail.com">atsticks@gmail.com</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Staging is not a question of xml or not xml (the &quot;format&quot; of<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; config).<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; You can do staged config also using xml, or based on a database<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; or json<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; config service. Staging as well as, more generally speaking,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; environment<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; dependent config is more like to select/filter the right config<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; that targets<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; the current (runtime) environment. This might include stages,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; but also many<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; other aspects are feasible and common (server, tier, ear, war,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; tenant ...).<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Since these aspects are per se very complex, it might be<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; advisable to leave<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; them out of any spec (even a dedicated config JSR would probably<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; not be<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; capable of covering these within the relatively short EE<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; timeframe)...<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; 2014-09-05 23:30 GMT+02:00 Werner Keil &lt;<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>&gt;:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Jens/all,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; A sort of &quot;staging&quot; already was possible using CDI earlier, see<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; examples like this:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war" target="_blank">http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; DeltaSpike also includes type-safe staging that goes beyond the<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; primitive, hard-coded JSF enum.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; If that works without XML, while still allowing flexible<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; configuration<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; for different stages  or to add and &quot;inject&quot; additional stages<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; maybe even on<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; a tenant basis (for Cloud scenarios) I could see something like<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; that work<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; without XML. In the Multiconf project we managed to code<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; everything in<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Python, and similar to Puppet or Chef you can configure and<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; deploy multiple<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; environments with it, Java EE, Spring or Play! several of them<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; are<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; configured this way and it requires no XML (where the container<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; needs such<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; files, the framework generates them;-)<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Werner<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; On Fri, Sep 5, 2014 at 10:21 PM,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.org</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Send cdi-dev mailing list submissions to<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;         <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; To subscribe or unsubscribe via the World Wide Web, visit<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;         <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; or, via email, send a message with subject or body &#39;help&#39; to<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;         <a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; You can reach the person managing the list at<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;         <a href="mailto:cdi-dev-owner@lists.jboss.org">cdi-dev-owner@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; When replying, please edit your Subject line so it is more<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; specific<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; than &quot;Re: Contents of cdi-dev digest...&quot;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Today&#39;s Topics:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;    1. Re: Tools : Google Drive vs Asciidoc and Github (Anatole<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Tresch)<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;    2. Re: With the end of Java Config... (Anatole Tresch)<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;    3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;       (Anatole Tresch (JIRA))<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;    4. Re: With the end of Java Config... (Jens Schumann)<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; ------------------------------<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Message: 4<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Date: Fri, 5 Sep 2014 20:20:53 +0000<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; From: Jens Schumann &lt;<a href="mailto:jens.schumann@openknowledge.de">jens.schumann@openknowledge.de</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Subject: Re: [cdi-dev] With the end of Java Config...<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; To: Anatole Tresch &lt;<a href="mailto:atsticks@gmail.com">atsticks@gmail.com</a>&gt;, Antonio Goncalves<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;         &lt;<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Cc: cdi-dev &lt;<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Message-ID: &lt;<a href="mailto:D02FDD99.396B9%25jens.schumann@openknowledge.de">D02FDD99.396B9%jens.schumann@openknowledge.de</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Content-Type: text/plain; charset=&quot;windows-1252&quot;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; I can confirm that this approach works very well. We are using a<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; similar approach a couple of years now, and I love the<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; simplicity that comes<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; with portable extensions and @Producer methods. See our public<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; version here<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; [1] (works since early CDI 1.0 days) .<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Instead of a @Inject + Qualifier we just use the qualifier<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; @Property.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; We support default values and type conversation for primitives<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; and<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; everything that has a string based constructor. The property<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; source can be<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; anything, from property files (default) to databases or xml<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; files. For<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; examples see tests here [2].<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Nevertheless I am not sure if this should be part of an future<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; CDI<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; spec. My concerns include the bloat argument, of course. But the<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; main reason<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; relates to the fact that we have almost everything in the<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; current CDI spec<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; already.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Right now I am quite happy with an custom portable extension<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; that does<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; everything for me. At the time we implemented the extension we<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; realised that<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; the &quot;hard part&quot; was writing an extension that links a qualified<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; &quot;optional<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; injection point&quot; with an @Producer method while supporting code<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; based<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; default values. Luckily I had Arne in my team who did that<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; within a few<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; minutes.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Because of this experience I would propose that we simplify<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; extension<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; development such that &quot;optional injection points&quot; may be linked<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; to @Produces<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; values easily. Additionally we have to solve a few more<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; integration issues<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; (e.g. read-only DB access should be available during CDI<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; startup).<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Everything else should be provided by portable extensions (e.g.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; via<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; delta-spike) and documentation/howtos at <a href="http://cdi-spec.org" target="_blank">cdi-spec.org</a>.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Jens<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; [1]<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property" target="_blank">https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; [2]<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property" target="_blank">https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Von: Anatole Tresch<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:atsticks@gmail.com">atsticks@gmail.com</a>&lt;mailto:<a href="mailto:atsticks@gmail.com">atsticks@gmail.com</a>&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Datum: Friday 5 September 2014 21:22<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; An: Antonio Goncalves<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>&lt;mailto:<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Cc: CDI-Dev<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&lt;mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Betreff: Re: [cdi-dev] With the end of Java Config...<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Hi all,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; I would not like to add an XML &quot;bloated&quot; mechanism as part of<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; CDI 2.0.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Spontaneously I would propose a more CDI like things like:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;   *   Adding a @Configured annotation (basically a qualifier).<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; This<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; can be in addition to @Inject and would allow to inject<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; &quot;configured&quot; values.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;   *   Since configuration can change we may think of a (CDI)<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; event/reinject mechanism based on config changes. By default,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; this is<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; switched off and we can discuss how it would be activated, e.g.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; by an<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; additional flag settable with the @Configured annotation, or an<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; additional<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; @Observable ConfigChangeEvent (similar to the Griffon<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; framework), or both.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;   *   Hereby configured values theoretically behave similar as<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; all<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; other injection points. They also can be qualified (the aspect<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; of scopes, I<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; did not yet have time to think about). The only difference is,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; that they are<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; satisified using the configuration &quot;system&quot;.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;   *   The configuration &quot;source&quot; itself could in the extreme<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; simplest<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; way be a Provider&lt;Map&lt;String,String&gt;&gt;. The CDI spec should not<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; care about<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; how this map is provided (XML, DB, overrides, etc). This still<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; can be<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; standardized later. As long as the ConfigurationSource SPI is<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; defined,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; companies still can hook in the logic and level of configuration<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; abstraction<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; they need.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;   *   Of course, since not only Strings can be injected, we need<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; some<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; conversion or adapter logic as basically outlined in my blog.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Also here we<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; can add a simple SPI and let the details to the RI.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Summarizing a<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;   *   @Configured annotation<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;   *   some kind of change event<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;   *   a ConfigurationSource extends Provider&lt;MapString,String&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;   *   a conversion mechanism from String to T.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; we get a full fledged configuration mechanism that leverages<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; CDI.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; That would be my idea basically. WDYT? I will try to work that<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; out in<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; more details. Basically it should be implementable even with the<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; CDI<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; mechanism already in place with CDI 1.1.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Best,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Anatole<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; 2014-09-05 16:08 GMT+02:00 Antonio Goncalves<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>&lt;mailto:<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>&gt;&gt;:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; One wise man* once said &quot;EJB was a hype specification, we added<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; too<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; many things to it, it became bloated. The next hype<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; specifications are<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; JAX-RS and CDI, careful with them&quot;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Either we get this idea of &quot;parts&quot; right, or CDI will endup<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; being<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; bloated.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Antonio<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; *David Blevin<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>&lt;mailto:<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Hi all,<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; You may have followed the rise and fall of the Java Config JSR<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; (<a href="http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html" target="_blank">http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html</a>).<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Anatole in CC was leading this initiative and I proposed him to<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; join<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; us and explore if some part of his late-JSR could be done in<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; CDI.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; I?m mainly thinking of <a href="https://issues.jboss.org/browse/CDI-123" target="_blank">https://issues.jboss.org/browse/CDI-123</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; or<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; related solution. If we achieve to have a majority of specs to<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; integrate<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; with CDI, our configuration solution would therefore become a<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; configuration<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; system for all spec based on CDI 2.0.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Antoine<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; cdi-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&lt;mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Note that for all code provided on this list, the provider<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; licenses<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; the code under the Apache License, Version 2<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; ideas<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; provided on this list, the provider waives all patent and other<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; intellectual<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; property rights inherent in such information.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Antonio Goncalves<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Software architect, Java Champion and Pluralsight author<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Web site&lt;<a href="http://www.antoniogoncalves.org" target="_blank">http://www.antoniogoncalves.org</a>&gt; |<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Twitter&lt;<a href="http://twitter.com/agoncal" target="_blank">http://twitter.com/agoncal</a>&gt; |<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; LinkedIn&lt;<a href="http://www.linkedin.com/in/agoncal" target="_blank">http://www.linkedin.com/in/agoncal</a>&gt; |<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Pluralsight&lt;<a href="http://pluralsight.com/training/Authors/Details/antonio-goncalves" target="_blank">http://pluralsight.com/training/Authors/Details/antonio-goncalves</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; | Paris JUG&lt;<a href="http://www.parisjug.org" target="_blank">http://www.parisjug.org</a>&gt; | Devoxx<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; France&lt;<a href="http://www.devoxx.fr" target="_blank">http://www.devoxx.fr</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; cdi-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&lt;mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Note that for all code provided on this list, the provider<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; licenses<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; the code under the Apache License, Version 2<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; ideas<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; provided on this list, the provider waives all patent and other<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; intellectual<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; property rights inherent in such information.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Anatole Tresch<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Java Lead Engineer, JSR Spec Lead<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Gl?rnischweg 10<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; CH - 8620 Wetzikon<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Switzerland, Europe Zurich, GMT+1<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Twitter:  @atsticks<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Blogs: <a href="http://javaremarkables.blogspot.ch/" target="_blank">http://javaremarkables.blogspot.ch/</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Google: atsticks<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Mobile  <a href="tel:%2B41-76%20344%2062%2079" value="+41763446279">+41-76 344 62 79</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; -------------- next part --------------<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; An HTML attachment was scrubbed...<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; URL:<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.html" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.html</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; ------------------------------<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; cdi-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Note that for all code provided on this list, the provider<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; licenses<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; the code under the Apache License, Version 2<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).  For all<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; other ideas<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; provided on this list, the provider waives all patent and other<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; intellectual<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; property rights inherent in such information.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; End of cdi-dev Digest, Vol 46, Issue 20<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; ***************************************<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; cdi-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Note that for all code provided on this list, the provider<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; licenses<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; the code under the Apache License, Version 2<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; ideas<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; provided on this list, the provider waives all patent and other<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; intellectual<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; property rights inherent in such information.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Anatole Tresch<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Java Lead Engineer, JSR Spec Lead<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Glärnischweg 10<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; CH - 8620 Wetzikon<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Switzerland, Europe Zurich, GMT+1<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Twitter:  @atsticks<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Blogs: <a href="http://javaremarkables.blogspot.ch/" target="_blank">http://javaremarkables.blogspot.ch/</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Google: atsticks<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Mobile  +41-76 344 62 79<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; cdi-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Note that for all code provided on this list, the provider<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; licenses<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; the code under the Apache License, Version 2<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; ideas<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; provided on this list, the provider waives all patent and other<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; intellectual<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; property rights inherent in such information.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; cdi-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Note that for all code provided on this list, the provider<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; licenses<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; the code under the Apache License, Version 2<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; ideas<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; provided on this list, the provider waives all patent and other<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; intellectual<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; property rights inherent in such information.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; cdi-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Note that for all code provided on this list, the provider<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; licenses<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; the code under the Apache License, Version 2<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; ideas<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; provided on this list, the provider waives all patent and other<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; intellectual<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; property rights inherent in such information.<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Anatole Tresch<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Java Lead Engineer, JSR Spec Lead<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Glärnischweg 10<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; CH - 8620 Wetzikon<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Switzerland, Europe Zurich, GMT+1<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Twitter:  @atsticks<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Blogs: <a href="http://javaremarkables.blogspot.ch/" target="_blank">http://javaremarkables.blogspot.ch/</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Google: atsticks<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Mobile  +41-76 344 62 79<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; --<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; Anatole Tresch<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; Java Lead Engineer, JSR Spec Lead<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; Glärnischweg 10<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; CH - 8620 Wetzikon<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; Switzerland, Europe Zurich, GMT+1<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; Twitter:  @atsticks<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; Blogs: <a href="http://javaremarkables.blogspot.ch/" target="_blank">http://javaremarkables.blogspot.ch/</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; Google: atsticks<br>
&gt;&gt;&gt;&gt;&gt; &gt;&gt; Mobile  +41-76 344 62 79<br>
&gt;&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt; &gt; cdi-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt; &gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt; &gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt;&gt; &gt; Note that for all code provided on this list, the provider licenses<br>
&gt;&gt;&gt;&gt;&gt; &gt; the code<br>
&gt;&gt;&gt;&gt;&gt; &gt; under the Apache License, Version 2<br>
&gt;&gt;&gt;&gt;&gt; &gt; (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
&gt;&gt;&gt;&gt;&gt; &gt; ideas<br>
&gt;&gt;&gt;&gt;&gt; &gt; provided on this list, the provider waives all patent and other<br>
&gt;&gt;&gt;&gt;&gt; &gt; intellectual<br>
&gt;&gt;&gt;&gt;&gt; &gt; property rights inherent in such information.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt; Anatole Tresch<br>
&gt;&gt;&gt;&gt; Java Lead Engineer, JSR Spec Lead<br>
&gt;&gt;&gt;&gt; Glärnischweg 10<br>
&gt;&gt;&gt;&gt; CH - 8620 Wetzikon<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Switzerland, Europe Zurich, GMT+1<br>
&gt;&gt;&gt;&gt; Twitter:  @atsticks<br>
&gt;&gt;&gt;&gt; Blogs: <a href="http://javaremarkables.blogspot.ch/" target="_blank">http://javaremarkables.blogspot.ch/</a><br>
&gt;&gt;&gt;&gt; Google: atsticks<br>
&gt;&gt;&gt;&gt; Mobile  +41-76 344 62 79<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; cdi-dev mailing list<br>
&gt;&gt;&gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Note that for all code provided on this list, the provider licenses the<br>
&gt;&gt;&gt; code under the Apache License, Version 2<br>
&gt;&gt;&gt; (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
&gt;&gt;&gt; provided on this list, the provider waives all patent and other intellectual<br>
&gt;&gt;&gt; property rights inherent in such information.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Antonio Goncalves<br>
&gt;&gt; Software architect, Java Champion and Pluralsight author<br>
&gt;&gt;<br>
</div></div>&gt;&gt; Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Antonio Goncalves <br>Software architect, Java Champion and Pluralsight author<br><br><a href="http://www.antoniogoncalves.org" target="_blank">Web site</a> | <a href="http://twitter.com/agoncal" target="_blank">Twitter</a> | <a href="http://www.linkedin.com/in/agoncal" target="_blank">LinkedIn</a> | <a href="http://pluralsight.com/training/Authors/Details/antonio-goncalves" target="_blank">Pluralsight</a> | <a href="http://www.parisjug.org" target="_blank">Paris JUG</a> | <a href="http://www.devoxx.fr" target="_blank">Devoxx France</a></div>
</div>