CDI extension, like DeltaSpike ;-)
Sounds reasonable,
Werner
On Mon, Sep 8, 2014 at 9:35 PM, Anatole Tresch <atsticks(a)gmail.com> wrote:
Therefore we should probably think of
- ensure we have hooks in CDI 2, where we can put the config mechanism
into to configure (control?) CDI itself.
All the rest can be done by just deploying and activating a CDI extension.
I will write a blog on that soon (it is already working here on my machine
with CDI 1.2 ;-) ).
Then we should try getting a SE JSR up and running (let us discuss that
during J1 and at the next EC meeting) to define how we define, assemble and
manage config in general. CDI then is only one of multiple possible
consumers.
-Anatole
2014-09-08 17:20 GMT+02:00 Mark Struberg <struberg(a)yahoo.de>:
> Antonio, the problem is that the config mechanism would need to be plain
> old java. In the best case even without classpath scanning.
> We need it during the boot time of the container (CDI and all other EE
> components boot time) so we cannot use CDI mechanics.
>
> If you look at DeltaSpike you will see that ConfigResolver just uses
> plain static methods. This is the only way we can use the config mechanism
> during boot time, e.g. to exclude classes in ProcessAnnotatedType, etc.
>
> The CDI part are only a few producers on top of it. We really need some
> common ground for configuration, but I don't think the CDI spec is the
> place where it should be handled...
>
> LieGrue,
> strub
>
>
>
> On Monday, 8 September 2014, 15:32, Antonio Goncalves <
> antonio.goncalves(a)gmail.com> wrote:
>
>
>
> 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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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-pr...
> >>>>> >>>>>>
> >>>>> >>>>>> 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(a)lists.jboss.org>
> >>>>> >>>>>> wrote:
> >>>>> >>>>>>
> >>>>> >>>>>> Send cdi-dev mailing list submissions
to
> >>>>> >>>>>> cdi-dev(a)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(a)lists.jboss.org
> >>>>> >>>>>>
> >>>>> >>>>>> You can reach the person managing the
list at
> >>>>> >>>>>> cdi-dev-owner(a)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(a)openknowledge.de>
> >>>>> >>>>>> Subject: Re: [cdi-dev] With the end of
Java Config...
> >>>>> >>>>>> To: Anatole Tresch
<atsticks(a)gmail.com>, Antonio Goncalves
> >>>>> >>>>>>
<antonio.goncalves(a)gmail.com>
> >>>>> >>>>>> Cc: cdi-dev
<cdi-dev(a)lists.jboss.org>
> >>>>> >>>>>> Message-ID:
<D02FDD99.396B9%jens.schumann(a)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...
> >>>>> >>>>>> [2]
> >>>>> >>>>>>
> >>>>> >>>>>>
>
https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master...
> >>>>> >>>>>>
> >>>>> >>>>>> Von: Anatole Tresch
> >>>>> >>>>>>
<atsticks@gmail.com<mailto:atsticks@gmail.com>>
> >>>>> >>>>>> Datum: Friday 5 September 2014 21:22
> >>>>> >>>>>> An: Antonio Goncalves
> >>>>> >>>>>>
> >>>>> >>>>>>
<antonio.goncalves(a)gmail.com<mailto:
> antonio.goncalves(a)gmail.com>>
> >>>>> >>>>>> Cc: CDI-Dev
> >>>>> >>>>>>
<cdi-dev@lists.jboss.org<mailto:cdi-dev@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(a)gmail.com<mailto:
> antonio.goncalves(a)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@sabot-durand.net<mailto:antoine@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-...
> ).
> >>>>> >>>>>> 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@lists.jboss.org<mailto:cdi-dev@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@lists.jboss.org<mailto:cdi-dev@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/at...
> >>>>> >>>>>>
> >>>>> >>>>>> ------------------------------
> >>>>> >>>>>>
> >>>>> >>>>>>
_______________________________________________
> >>>>> >>>>>> cdi-dev mailing list
> >>>>> >>>>>> cdi-dev(a)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(a)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(a)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(a)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(a)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(a)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(a)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 <
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(a)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(a)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/
<
http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*