[cdi-dev] With the end of Java Config...

[Romain Manni-Bucau]

like the last one but do you think CDI will get time for it + is it
really the place?


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


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