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/
<