[cdi-dev] With the end of Java Config...
Werner Keil
werner.keil at gmail.com
Sun Sep 7 08:41:37 EDT 2014
Maybe not all keys, but VALUES are, if you ever worked in a true Cloud or
DevOps environment?;-)
That's exactly what we did e.g. with the Multiconf DevOps framework:
https://github.com/lhupfeldt/multiconf
While written in Python, it allowed Java EE aps (on more than just one
container, JBoss, WLS, Play it covers all;-) to handle multiple stages and
configuration.
This way doing so on a (continuous) delivery level, a JAR, WAR or similar
artifact and all config data are tailor-made for a stage, I believe, from
what Anatole mentioned, this could also be sort of Oracle's preference for
config management in Java (sort of helping Maven, Ant, Gradle or CI tools
like Multiconf;-) but DeltaSpike and other config solutions including
Spring Config usually do this at runtime, too. Without the need of a JAR
per stage or tenant, it adapts and knows where it's running;-)
I saw many (Outsourcing) providers we helped with these things and some
indeed used something like
- LOG_FOLDER_ON_DEV
- LOG_FOLDER_ON_UAT
- LOG_FOLDER_ON_PROD
(you get the idea;-)
that is not what DeltaSpike config proposes and neither does Spring in most
cases.
Werner
On Sun, Sep 7, 2014 at 2:31 PM, John D. Ament <john.d.ament at gmail.com>
wrote:
> Yeah... personally, I dislike project stage. I for one would be hung out
> to dry if I ever mixed my dev/test/prd environment configs in one file.
> Much more, my devops would treat me like a pinata if I told them the
> configuration keys were different in each environment... :-)
>
>
> On Sun, Sep 7, 2014 at 8:29 AM, 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/
>>>> <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/99c2ac33/attachment-0001.html
More information about the cdi-dev
mailing list