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

[Anatole Tresch]

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

> 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> 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
>> 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
> 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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/0e7579de/attachment.html