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

Werner Keil werner.keil at gmail.com
Mon Sep 8 04:29:47 EDT 2014 

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/
>>> <http://javaremarkables.blogspot.ch/>*
>>>
>>> *Google: atsticksMobile  +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
>>>
>>
>> _______________________________________________
>> 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 <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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140908/fe7479a2/attachment-0001.html

More information about the cdi-dev mailing list