<div dir="ltr"><div>If DeltaSpike Configuration already covered everything there would have been no need for Tamaya;-)</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 6, 2015 at 1:23 PM, arjan tijms <span dir="ltr"><<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">Hi,<br>
<span><br>
On Fri, Feb 6, 2015 at 11:22 AM, Werner Keil <<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>> wrote:<br>
> but so far JCP officials first and foremost<br>
> Oracle saw either no need or no resources to do this.<br>
<br>
</span>I remember some other issues being on the table, like Java SE vs Java<br>
EE and "configuring the runtime" vs "injecting/providing values to the<br>
app".<br>
<br>
DeltaSpike Configuration is really great, but it's a value provider.<br>
It doesn't let you swap out or overlay deployment descriptors etc.<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
><br>
> Apache Tamaya was a logical result. If that could become a blue-print or<br>
> initial contribution of a future JSR, let's see, maybe for EE 9. It uses<br>
> other Apache projects like DeltaSpike where applicable, but may also define<br>
> such annotations and types of its own, so I suggest you also share your<br>
> ideas on a Tamaya mailing list or JIRA:<br>
> <a href="http://tamaya.incubator.apache.org/index.html" target="_blank">http://tamaya.incubator.apache.org/index.html</a><br>
><br>
> On Fri, Feb 6, 2015 at 11:02 AM, <<a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.org</a>> wrote:<br>
>><br>
>> Send cdi-dev mailing list submissions to<br>
>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>><br>
>> To subscribe or unsubscribe via the World Wide Web, visit<br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>> or, via email, send a message with subject or body 'help' to<br>
>> <a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.org</a><br>
>><br>
>> You can reach the person managing the list at<br>
>> <a href="mailto:cdi-dev-owner@lists.jboss.org">cdi-dev-owner@lists.jboss.org</a><br>
>><br>
>> When replying, please edit your Subject line so it is more specific<br>
>> than "Re: Contents of cdi-dev digest..."<br>
>><br>
>><br>
>> Today's Topics:<br>
>><br>
>> 1. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>> @ConfigProperty from deltapsike (James Strachan (JIRA))<br>
>> 2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>> @ConfigProperty from deltapsike (Martin Kouba (JIRA))<br>
>> 3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>> @ConfigProperty from deltapsike (John Ament (JIRA))<br>
>> 4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>> @ConfigProperty from deltapsike (James Strachan (JIRA))<br>
>> 5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>> @ConfigProperty from deltapsike (James Strachan (JIRA))<br>
>> 6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>> @ConfigProperty from deltapsike (James Strachan (JIRA))<br>
>> 7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>> @ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA))<br>
>><br>
>><br>
>> ----------------------------------------------------------------------<br>
>><br>
>> Message: 1<br>
>> Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST)<br>
>> From: "James Strachan (JIRA)" <<a href="mailto:issues@jboss.org">issues@jboss.org</a>><br>
>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>> annotation like @ConfigProperty from deltapsike<br>
>> To: <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> Message-ID:<br>
>> <JIRA.12562481.1423130482000.44616.1423130509034@Atlassian.JIRA><br>
>> Content-Type: text/plain; charset=UTF-8<br>
>><br>
>> James Strachan created CDI-504:<br>
>> ----------------------------------<br>
>><br>
>> Summary: have a standard CDI annotation like @ConfigProperty<br>
>> from deltapsike<br>
>> Key: CDI-504<br>
>> URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/browse/CDI-504</a><br>
>> Project: CDI Specification Issues<br>
>> Issue Type: Feature Request<br>
>> Reporter: James Strachan<br>
>><br>
>><br>
>> Docker and containerisation is the new hotness; in the docker world images<br>
>> are static and the main way of injecting configuration is via environment<br>
>> variables - so that the same image can be reused but configured at run time<br>
>> with different configuration values. (Changing configuration files requires<br>
>> either different images to be created or using custom volumes which is less<br>
>> ideal in a containerized world).<br>
>><br>
>> So IMHO CDI should provide a simple, natural way to allow environment<br>
>> variables (or system properties) to be easily injected via CDI.<br>
>><br>
>> Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>> <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/documentation/configuration.html</a><br>
>><br>
>> you can specify a name, default value and use it on an @Inject to provide<br>
>> a value from env vars, system properties or provide a default.<br>
>><br>
>> Given how core and useful this is - it feels like it should be part of the<br>
>> CDI specification; its one simple annotation.<br>
>><br>
>> Currently deltaspike provides a way to configure different sources and<br>
>> whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>> which was only bound to env vars / system properties.<br>
>><br>
>> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>><br>
>> There could be debate on whether env vars or system properties should win<br>
>> if the same name is used for both; in a dockerized world I'd prefer env vars<br>
>> to win but folks can always tinker with their run command to make sure they<br>
>> pass in env vars as system properties to work around this I guess.<br>
>><br>
>><br>
>><br>
>> --<br>
>> This message was sent by Atlassian JIRA<br>
>> (v6.3.11#6341)<br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 2<br>
>> Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST)<br>
>> From: "Martin Kouba (JIRA)" <<a href="mailto:issues@jboss.org">issues@jboss.org</a>><br>
>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>> annotation like @ConfigProperty from deltapsike<br>
>> To: <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> Message-ID:<br>
>> <JIRA.12562481.1423130482000.45712.1423150250888@Atlassian.JIRA><br>
>> Content-Type: text/plain; charset=UTF-8<br>
>><br>
>><br>
>> [<br>
>> <a href="https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038005#comment-13038005" target="_blank">https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038005#comment-13038005</a><br>
>> ]<br>
>><br>
>> Martin Kouba commented on CDI-504:<br>
>> ----------------------------------<br>
>><br>
>> What's wrong with {{java.lang.System.getProperty()}} and<br>
>> {{java.lang.System.getenv()}}? I mean the main advantage of DS Configuration<br>
>> is IMO the resolution mechanism and the ability to extend the set of<br>
>> {{ConfigSource}} s. If you only need system properties and env variables a<br>
>> simple producer method and qualifier (or even a simple util method) would be<br>
>> sufficient. In other words I see no reason to standardize this.<br>
>><br>
>> > have a standard CDI annotation like @ConfigProperty from deltapsike<br>
>> > -------------------------------------------------------------------<br>
>> ><br>
>> > Key: CDI-504<br>
>> > URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/browse/CDI-504</a><br>
>> > Project: CDI Specification Issues<br>
>> > Issue Type: Feature Request<br>
>> > Reporter: James Strachan<br>
>> ><br>
>> > Docker and containerisation is the new hotness; in the docker world<br>
>> > images are static and the main way of injecting configuration is via<br>
>> > environment variables - so that the same image can be reused but configured<br>
>> > at run time with different configuration values. (Changing configuration<br>
>> > files requires either different images to be created or using custom volumes<br>
>> > which is less ideal in a containerized world).<br>
>> > So IMHO CDI should provide a simple, natural way to allow environment<br>
>> > variables (or system properties) to be easily injected via CDI.<br>
>> > Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>> > <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/documentation/configuration.html</a><br>
>> > you can specify a name, default value and use it on an @Inject to<br>
>> > provide a value from env vars, system properties or provide a default.<br>
>> > Given how core and useful this is - it feels like it should be part of<br>
>> > the CDI specification; its one simple annotation.<br>
>> > Currently deltaspike provides a way to configure different sources and<br>
>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>> > which was only bound to env vars / system properties.<br>
>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>> > There could be debate on whether env vars or system properties should<br>
>> > win if the same name is used for both; in a dockerized world I'd prefer env<br>
>> > vars to win but folks can always tinker with their run command to make sure<br>
>> > they pass in env vars as system properties to work around this I guess.<br>
>><br>
>><br>
>><br>
>> --<br>
>> This message was sent by Atlassian JIRA<br>
>> (v6.3.11#6341)<br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 3<br>
>> Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST)<br>
>> From: "John Ament (JIRA)" <<a href="mailto:issues@jboss.org">issues@jboss.org</a>><br>
>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>> annotation like @ConfigProperty from deltapsike<br>
>> To: <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> Message-ID:<br>
>> <JIRA.12562481.1423130482000.45725.1423150489341@Atlassian.JIRA><br>
>> Content-Type: text/plain; charset=UTF-8<br>
>><br>
>><br>
>> [<br>
>> <a href="https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038007#comment-13038007" target="_blank">https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038007#comment-13038007</a><br>
>> ]<br>
>><br>
>> John Ament commented on CDI-504:<br>
>> --------------------------------<br>
>><br>
>> A separate config JSR has been proposed previously to address this. They<br>
>> want to see more options before trying to standardize it.<br>
>><br>
>> > have a standard CDI annotation like @ConfigProperty from deltapsike<br>
>> > -------------------------------------------------------------------<br>
>> ><br>
>> > Key: CDI-504<br>
>> > URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/browse/CDI-504</a><br>
>> > Project: CDI Specification Issues<br>
>> > Issue Type: Feature Request<br>
>> > Reporter: James Strachan<br>
>> ><br>
>> > Docker and containerisation is the new hotness; in the docker world<br>
>> > images are static and the main way of injecting configuration is via<br>
>> > environment variables - so that the same image can be reused but configured<br>
>> > at run time with different configuration values. (Changing configuration<br>
>> > files requires either different images to be created or using custom volumes<br>
>> > which is less ideal in a containerized world).<br>
>> > So IMHO CDI should provide a simple, natural way to allow environment<br>
>> > variables (or system properties) to be easily injected via CDI.<br>
>> > Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>> > <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/documentation/configuration.html</a><br>
>> > you can specify a name, default value and use it on an @Inject to<br>
>> > provide a value from env vars, system properties or provide a default.<br>
>> > Given how core and useful this is - it feels like it should be part of<br>
>> > the CDI specification; its one simple annotation.<br>
>> > Currently deltaspike provides a way to configure different sources and<br>
>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>> > which was only bound to env vars / system properties.<br>
>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>> > There could be debate on whether env vars or system properties should<br>
>> > win if the same name is used for both; in a dockerized world I'd prefer env<br>
>> > vars to win but folks can always tinker with their run command to make sure<br>
>> > they pass in env vars as system properties to work around this I guess.<br>
>><br>
>><br>
>><br>
>> --<br>
>> This message was sent by Atlassian JIRA<br>
>> (v6.3.11#6341)<br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 4<br>
>> Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST)<br>
>> From: "James Strachan (JIRA)" <<a href="mailto:issues@jboss.org">issues@jboss.org</a>><br>
>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>> annotation like @ConfigProperty from deltapsike<br>
>> To: <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> Message-ID:<br>
>> <JIRA.12562481.1423130482000.45741.1423150789541@Atlassian.JIRA><br>
>> Content-Type: text/plain; charset=UTF-8<br>
>><br>
>><br>
>> [<br>
>> <a href="https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012" target="_blank">https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012</a><br>
>> ]<br>
>><br>
>> James Strachan commented on CDI-504:<br>
>> ------------------------------------<br>
>><br>
>> @Resource is supported - injecting values from JNDI. I don't see why<br>
>> injecting values (with a default value) from the environment isn't also<br>
>> supported too. There's a Java API for JNDI too so folks could look stuff up<br>
>> in JNDI by hand and do the type conversions - but we've injection for those<br>
>> values.<br>
>><br>
>> Its also much cleaner code and can easily deal generically with type<br>
>> conversion to long/double/float/date etc.<br>
>><br>
>> Compare:<br>
>> {code}<br>
>> @Inject Foo(int bar, ...) {<br>
>> bar = System.getenv("FOO");<br>
>> if (bar == null) {<br>
>> bar = "someDefault";<br>
>> }<br>
>> // now convert to a String with error handling....<br>
>> }<br>
>> {code}<br>
>> to just:<br>
>> {code}<br>
>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {<br>
>> }<br>
>> {code}<br>
>><br>
>> Also by using an annotation it means its very easy to generate<br>
>> documentation and tooling. (e.g. using APT you can know what all the<br>
>> environment variables are used by CDI; either to report on demand or to<br>
>> generate user documentation).<br>
>><br>
>><br>
>><br>
>> > have a standard CDI annotation like @ConfigProperty from deltapsike<br>
>> > -------------------------------------------------------------------<br>
>> ><br>
>> > Key: CDI-504<br>
>> > URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/browse/CDI-504</a><br>
>> > Project: CDI Specification Issues<br>
>> > Issue Type: Feature Request<br>
>> > Reporter: James Strachan<br>
>> ><br>
>> > Docker and containerisation is the new hotness; in the docker world<br>
>> > images are static and the main way of injecting configuration is via<br>
>> > environment variables - so that the same image can be reused but configured<br>
>> > at run time with different configuration values. (Changing configuration<br>
>> > files requires either different images to be created or using custom volumes<br>
>> > which is less ideal in a containerized world).<br>
>> > So IMHO CDI should provide a simple, natural way to allow environment<br>
>> > variables (or system properties) to be easily injected via CDI.<br>
>> > Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>> > <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/documentation/configuration.html</a><br>
>> > you can specify a name, default value and use it on an @Inject to<br>
>> > provide a value from env vars, system properties or provide a default.<br>
>> > Given how core and useful this is - it feels like it should be part of<br>
>> > the CDI specification; its one simple annotation.<br>
>> > Currently deltaspike provides a way to configure different sources and<br>
>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>> > which was only bound to env vars / system properties.<br>
>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>> > There could be debate on whether env vars or system properties should<br>
>> > win if the same name is used for both; in a dockerized world I'd prefer env<br>
>> > vars to win but folks can always tinker with their run command to make sure<br>
>> > they pass in env vars as system properties to work around this I guess.<br>
>><br>
>><br>
>><br>
>> --<br>
>> This message was sent by Atlassian JIRA<br>
>> (v6.3.11#6341)<br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 5<br>
>> Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST)<br>
>> From: "James Strachan (JIRA)" <<a href="mailto:issues@jboss.org">issues@jboss.org</a>><br>
>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>> annotation like @ConfigProperty from deltapsike<br>
>> To: <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> Message-ID:<br>
>> <JIRA.12562481.1423130482000.45763.1423151389408@Atlassian.JIRA><br>
>> Content-Type: text/plain; charset=UTF-8<br>
>><br>
>><br>
>> [<br>
>> <a href="https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012" target="_blank">https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012</a><br>
>> ]<br>
>><br>
>> James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM:<br>
>> -------------------------------------------------------------<br>
>><br>
>> @Resource is supported - injecting values from JNDI. I don't see why<br>
>> injecting values (with a default value) from the environment isn't also<br>
>> supported too. There's a Java API for JNDI too so folks could look stuff up<br>
>> in JNDI by hand and do the type conversions - but we've injection for those<br>
>> values.<br>
>><br>
>> Its also much cleaner code and can easily deal generically with type<br>
>> conversion to long/double/float/date etc.<br>
>><br>
>> Compare:<br>
>> {code}<br>
>> @Inject Foo(int bar, ...) {<br>
>> bar = System.getenv("FOO");<br>
>> if (bar == null) {<br>
>> bar = "someDefault";<br>
>> }<br>
>> // now convert the String to an int with nice error handling and<br>
>> reporting....<br>
>> }<br>
>> {code}<br>
>> to just:<br>
>> {code}<br>
>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {<br>
>> }<br>
>> {code}<br>
>><br>
>> Also by using an annotation it means its very easy to generate<br>
>> documentation and tooling. (e.g. using APT you can know what all the<br>
>> environment variables are used by CDI; either to report on demand or to<br>
>> generate user documentation).<br>
>><br>
>><br>
>><br>
>><br>
>> was (Author: jastrachan):<br>
>> @Resource is supported - injecting values from JNDI. I don't see why<br>
>> injecting values (with a default value) from the environment isn't also<br>
>> supported too. There's a Java API for JNDI too so folks could look stuff up<br>
>> in JNDI by hand and do the type conversions - but we've injection for those<br>
>> values.<br>
>><br>
>> Its also much cleaner code and can easily deal generically with type<br>
>> conversion to long/double/float/date etc.<br>
>><br>
>> Compare:<br>
>> {code}<br>
>> @Inject Foo(int bar, ...) {<br>
>> bar = System.getenv("FOO");<br>
>> if (bar == null) {<br>
>> bar = "someDefault";<br>
>> }<br>
>> // now convert to a String with error handling....<br>
>> }<br>
>> {code}<br>
>> to just:<br>
>> {code}<br>
>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {<br>
>> }<br>
>> {code}<br>
>><br>
>> Also by using an annotation it means its very easy to generate<br>
>> documentation and tooling. (e.g. using APT you can know what all the<br>
>> environment variables are used by CDI; either to report on demand or to<br>
>> generate user documentation).<br>
>><br>
>><br>
>><br>
>> > have a standard CDI annotation like @ConfigProperty from deltapsike<br>
>> > -------------------------------------------------------------------<br>
>> ><br>
>> > Key: CDI-504<br>
>> > URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/browse/CDI-504</a><br>
>> > Project: CDI Specification Issues<br>
>> > Issue Type: Feature Request<br>
>> > Reporter: James Strachan<br>
>> ><br>
>> > Docker and containerisation is the new hotness; in the docker world<br>
>> > images are static and the main way of injecting configuration is via<br>
>> > environment variables - so that the same image can be reused but configured<br>
>> > at run time with different configuration values. (Changing configuration<br>
>> > files requires either different images to be created or using custom volumes<br>
>> > which is less ideal in a containerized world).<br>
>> > So IMHO CDI should provide a simple, natural way to allow environment<br>
>> > variables (or system properties) to be easily injected via CDI.<br>
>> > Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>> > <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/documentation/configuration.html</a><br>
>> > you can specify a name, default value and use it on an @Inject to<br>
>> > provide a value from env vars, system properties or provide a default.<br>
>> > Given how core and useful this is - it feels like it should be part of<br>
>> > the CDI specification; its one simple annotation.<br>
>> > Currently deltaspike provides a way to configure different sources and<br>
>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>> > which was only bound to env vars / system properties.<br>
>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>> > There could be debate on whether env vars or system properties should<br>
>> > win if the same name is used for both; in a dockerized world I'd prefer env<br>
>> > vars to win but folks can always tinker with their run command to make sure<br>
>> > they pass in env vars as system properties to work around this I guess.<br>
>><br>
>><br>
>><br>
>> --<br>
>> This message was sent by Atlassian JIRA<br>
>> (v6.3.11#6341)<br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 6<br>
>> Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST)<br>
>> From: "James Strachan (JIRA)" <<a href="mailto:issues@jboss.org">issues@jboss.org</a>><br>
>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>> annotation like @ConfigProperty from deltapsike<br>
>> To: <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> Message-ID:<br>
>> <JIRA.12562481.1423130482000.45773.1423151449139@Atlassian.JIRA><br>
>> Content-Type: text/plain; charset=UTF-8<br>
>><br>
>><br>
>> [<br>
>> <a href="https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012" target="_blank">https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012</a><br>
>> ]<br>
>><br>
>> James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM:<br>
>> -------------------------------------------------------------<br>
>><br>
>> @Resource is supported - injecting values from JNDI. I don't see why<br>
>> injecting values (with a default value) from the environment isn't also<br>
>> supported too. There's a Java API for JNDI too so folks could look stuff up<br>
>> in JNDI by hand and do the type conversions - but we've injection for those<br>
>> values.<br>
>><br>
>> Its also much cleaner code and can easily deal generically with type<br>
>> conversion to long/double/float/date etc.<br>
>><br>
>> Compare:<br>
>> {code}<br>
>> int bar;<br>
>> @Inject Foo() {<br>
>> barText = System.getenv("FOO");<br>
>> if (barText == null) {<br>
>> barText = "someDefault";<br>
>> }<br>
>> // now convert the String to an int with nice error handling and<br>
>> reporting....<br>
>> bar = someConvertCode(barText);<br>
>> }<br>
>> {code}<br>
>> to just:<br>
>> {code}<br>
>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {<br>
>> }<br>
>> {code}<br>
>><br>
>> Note that in the second case, folks could use the constructor explicitly<br>
>> without being bound to environment variables too; much cleaner, more modular<br>
>> code.<br>
>><br>
>> Also by using an annotation it means its very easy to generate<br>
>> documentation and tooling. (e.g. using APT you can know what all the<br>
>> environment variables are used by CDI; either to report on demand or to<br>
>> generate user documentation).<br>
>><br>
>><br>
>><br>
>><br>
>> was (Author: jastrachan):<br>
>> @Resource is supported - injecting values from JNDI. I don't see why<br>
>> injecting values (with a default value) from the environment isn't also<br>
>> supported too. There's a Java API for JNDI too so folks could look stuff up<br>
>> in JNDI by hand and do the type conversions - but we've injection for those<br>
>> values.<br>
>><br>
>> Its also much cleaner code and can easily deal generically with type<br>
>> conversion to long/double/float/date etc.<br>
>><br>
>> Compare:<br>
>> {code}<br>
>> @Inject Foo(int bar, ...) {<br>
>> bar = System.getenv("FOO");<br>
>> if (bar == null) {<br>
>> bar = "someDefault";<br>
>> }<br>
>> // now convert the String to an int with nice error handling and<br>
>> reporting....<br>
>> }<br>
>> {code}<br>
>> to just:<br>
>> {code}<br>
>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {<br>
>> }<br>
>> {code}<br>
>><br>
>> Also by using an annotation it means its very easy to generate<br>
>> documentation and tooling. (e.g. using APT you can know what all the<br>
>> environment variables are used by CDI; either to report on demand or to<br>
>> generate user documentation).<br>
>><br>
>><br>
>><br>
>> > have a standard CDI annotation like @ConfigProperty from deltapsike<br>
>> > -------------------------------------------------------------------<br>
>> ><br>
>> > Key: CDI-504<br>
>> > URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/browse/CDI-504</a><br>
>> > Project: CDI Specification Issues<br>
>> > Issue Type: Feature Request<br>
>> > Reporter: James Strachan<br>
>> ><br>
>> > Docker and containerisation is the new hotness; in the docker world<br>
>> > images are static and the main way of injecting configuration is via<br>
>> > environment variables - so that the same image can be reused but configured<br>
>> > at run time with different configuration values. (Changing configuration<br>
>> > files requires either different images to be created or using custom volumes<br>
>> > which is less ideal in a containerized world).<br>
>> > So IMHO CDI should provide a simple, natural way to allow environment<br>
>> > variables (or system properties) to be easily injected via CDI.<br>
>> > Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>> > <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/documentation/configuration.html</a><br>
>> > you can specify a name, default value and use it on an @Inject to<br>
>> > provide a value from env vars, system properties or provide a default.<br>
>> > Given how core and useful this is - it feels like it should be part of<br>
>> > the CDI specification; its one simple annotation.<br>
>> > Currently deltaspike provides a way to configure different sources and<br>
>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>> > which was only bound to env vars / system properties.<br>
>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>> > There could be debate on whether env vars or system properties should<br>
>> > win if the same name is used for both; in a dockerized world I'd prefer env<br>
>> > vars to win but folks can always tinker with their run command to make sure<br>
>> > they pass in env vars as system properties to work around this I guess.<br>
>><br>
>><br>
>><br>
>> --<br>
>> This message was sent by Atlassian JIRA<br>
>> (v6.3.11#6341)<br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 7<br>
>> Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST)<br>
>> From: "Antoine Sabot-Durand (JIRA)" <<a href="mailto:issues@jboss.org">issues@jboss.org</a>><br>
>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>> annotation like @ConfigProperty from deltapsike<br>
>> To: <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> Message-ID:<br>
>> <JIRA.12562481.1423130482000.47108.1423216969246@Atlassian.JIRA><br>
>> Content-Type: text/plain; charset=UTF-8<br>
>><br>
>><br>
>> [<br>
>> <a href="https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038271#comment-13038271" target="_blank">https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038271#comment-13038271</a><br>
>> ]<br>
>><br>
>> Antoine Sabot-Durand commented on CDI-504:<br>
>> ------------------------------------------<br>
>><br>
>> James, I don't get what's the problem with using DeltaSpike config<br>
>> solution?<br>
>><br>
>> > have a standard CDI annotation like @ConfigProperty from deltapsike<br>
>> > -------------------------------------------------------------------<br>
>> ><br>
>> > Key: CDI-504<br>
>> > URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/browse/CDI-504</a><br>
>> > Project: CDI Specification Issues<br>
>> > Issue Type: Feature Request<br>
>> > Reporter: James Strachan<br>
>> ><br>
>> > Docker and containerisation is the new hotness; in the docker world<br>
>> > images are static and the main way of injecting configuration is via<br>
>> > environment variables - so that the same image can be reused but configured<br>
>> > at run time with different configuration values. (Changing configuration<br>
>> > files requires either different images to be created or using custom volumes<br>
>> > which is less ideal in a containerized world).<br>
>> > So IMHO CDI should provide a simple, natural way to allow environment<br>
>> > variables (or system properties) to be easily injected via CDI.<br>
>> > Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>> > <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/documentation/configuration.html</a><br>
>> > you can specify a name, default value and use it on an @Inject to<br>
>> > provide a value from env vars, system properties or provide a default.<br>
>> > Given how core and useful this is - it feels like it should be part of<br>
>> > the CDI specification; its one simple annotation.<br>
>> > Currently deltaspike provides a way to configure different sources and<br>
>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>> > which was only bound to env vars / system properties.<br>
>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>> > There could be debate on whether env vars or system properties should<br>
>> > win if the same name is used for both; in a dockerized world I'd prefer env<br>
>> > vars to win but folks can always tinker with their run command to make sure<br>
>> > they pass in env vars as system properties to work around this I guess.<br>
>><br>
>><br>
>><br>
>> --<br>
>> This message was sent by Atlassian JIRA<br>
>> (v6.3.11#6341)<br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list, the provider licenses the<br>
>> code under the Apache License, Version 2<br>
>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>> provided on this list, the provider waives all patent and other intellectual<br>
>> property rights inherent in such information.<br>
>><br>
>> End of cdi-dev Digest, Vol 51, Issue 9<br>
>> **************************************<br>
><br>
><br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses the code<br>
> under the Apache License, Version 2<br>
> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
> provided on this list, the provider waives all patent and other intellectual<br>
> property rights inherent in such information.<br>
</div></div></blockquote></div><br></div></div>