[cdi-dev] With the end of Java Config...
Werner Keil
werner.keil at gmail.com
Mon Sep 8 06:33:12 EDT 2014
Apache allows that, especially for the Spec;-)
It's sort of similar with Stephen Colebourne's "backport". A project not
under "java.time" but some "org.threeten", so if what you allow them a
vendor XYZ created their Apache "fork" of the Spec then they may not
necessarily declare an API under "javax.*" but the are fine to do a "org.*"
or other fork, and the implementation will be compatible with "their" spec.
They could even do some sort of testing, or "certification" as long as they
don't call it "100% Pure Java";-D
Happened here for JSR-295:
https://kenai.com/projects/betterbeansbinding/pages/Home
To my knowledge that project did not rewrite the Spec (which would be
illegal under its terms) and I don't even want to bother about whether the
fork was legitimate then (before jcp.next) at all, since both projects are
now dead, but if a vendor wanted, they could fork projects like
"BetterBeanValidation" or "TDI" instead of "CDI" (just like car vendors do
with those names for often the same technology;-)
Werner
On Mon, Sep 8, 2014 at 12:11 PM, Pete Muir <pmuir at redhat.com> wrote:
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/6633f5bf/attachment-0001.html
More information about the cdi-dev
mailing list