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

Werner Keil werner.keil at gmail.com
Sun Sep 7 08:29:14 EDT 2014 

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/
>> <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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140907/37267d8d/attachment-0001.html

More information about the cdi-dev mailing list