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