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

Pete Muir pmuir at redhat.com
Mon Sep 8 06:11:34 EDT 2014 

On 8 Sep 2014, at 11:06, Werner Keil <werner.keil at gmail.com> wrote:

> As a side note, if the BV Spec is now Apache, those who want to write "their own flavor" of Spec and API can do so in these cases;-)
> Which is also why Anatole (and other EC Members talking to Oracle Legal, etc.) said, Oracle "tolerates" the Apache Licensing of even the Spec Document, but it is a two-headed sword for compatibility.
> 
> A vendor taking that spec and adding their own "appendix" would not be sued (like for other parts of the Java ecosystem;-p) but it may end up as a proprietary feature to that container alone. 

Right, but at this point they are no longer implementing “CDI”, they are now implementing “vendors-variation-of-CDI”...

> 
> If let's say a simple desktop app has no need for an extensible "stage" concept and API, then that's a perfect example where optionality just like under MEEP 8 makes sense in the SE/EE world, too. Not because of size, but choice and keeping the burden for developers (and implementors, if they don't want to use it) lower than e.g. with SE 8 and 5 different (mandatory) Date/Time APIs;-|
> 
> Werner
> 
> On Mon, Sep 8, 2014 at 11:51 AM, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> @Antonio: -1 for an appendix, bean validation is the example it is
> broken. Idea is awesome, everybody liked it so it was added -> great.
> Here everybody already agrees it is good so no need of "staging" phase
> IMHO. BV appendix was not the API used so it broke apps using it. SO
> using proprietary stuff is the same, it basically mean an appendix
> spec for something not under discussion (regarding its need) is IMHO
> useless.
> 
> 
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
> 
> 
> 2014-09-08 10:29 GMT+02:00 Werner Keil <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
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

More information about the cdi-dev mailing list