but so far JCP officials first and foremost Oracle saw either no need or no resources to do this.

Apache Tamaya was a logical result. If that could become a blue-print or initial contribution of a future JSR, let's see, maybe for EE 9. It uses other Apache projects like DeltaSpike where applicable, but may also define such annotations and types of its own, so I suggest you also share your ideas on a Tamaya mailing list or JIRA: http://tamaya.incubator.apache.org/index.html On Fri, Feb 6, 2015 at 11:02 AM, <cdi-dev-request(a)lists.jboss.org&gt; wrote: > > Send cdi-dev mailing list submissions to > cdi-dev(a)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(a)lists.jboss.org > > You can reach the person managing the list at > cdi-dev-owner(a)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. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (James Strachan (JIRA)) > 2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (Martin Kouba (JIRA)) > 3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (John Ament (JIRA)) > 4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (James Strachan (JIRA)) > 5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (James Strachan (JIRA)) > 6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (James Strachan (JIRA)) > 7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST) > From: "James Strachan (JIRA)" <issues(a)jboss.org&gt; > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev(a)lists.jboss.org > Message-ID: > <JIRA.12562481.1423130482000.44616.1423130509034(a)Atlassian.JIRA&gt; > Content-Type: text/plain; charset=UTF-8 > > James Strachan created CDI-504: > ---------------------------------- > > Summary: have a standard CDI annotation like @ConfigProperty > from deltapsike > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > > Docker and containerisation is the new hotness; in the docker world images > are static and the main way of injecting configuration is via environment > variables - so that the same image can be reused but configured at run time > with different configuration values. (Changing configuration files requires > either different images to be created or using custom volumes which is less > ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to provide > a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of the > CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should win > if the same name is used for both; in a dockerized world I'd prefer env vars > to win but folks can always tinker with their run command to make sure they > pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > Message: 2 > Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST) > From: "Martin Kouba (JIRA)" <issues(a)jboss.org&gt; > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev(a)lists.jboss.org > Message-ID: > <JIRA.12562481.1423130482000.45712.1423150250888(a)Atlassian.JIRA&gt; > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... > ] > > Martin Kouba commented on CDI-504: > ---------------------------------- > > What's wrong with {{java.lang.System.getProperty()}} and > {{java.lang.System.getenv()}}? I mean the main advantage of DS Configuration > is IMO the resolution mechanism and the ability to extend the set of > {{ConfigSource}} s. If you only need system properties and env variables a > simple producer method and qualifier (or even a simple util method) would be > sufficient. In other words I see no reason to standardize this. > > > have a standard CDI annotation like @ConfigProperty from deltapsike > > ------------------------------------------------------------------- > > > > Key: CDI-504 > > URL: https://issues.jboss.org/browse/CDI-504 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: James Strachan > > > > Docker and containerisation is the new hotness; in the docker world > > images are static and the main way of injecting configuration is via > > environment variables - so that the same image can be reused but configured > > at run time with different configuration values. (Changing configuration > > files requires either different images to be created or using custom volumes > > which is less ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to > > provide a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of > > the CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should > > win if the same name is used for both; in a dockerized world I'd prefer env > > vars to win but folks can always tinker with their run command to make sure > > they pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > Message: 3 > Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST) > From: "John Ament (JIRA)" <issues(a)jboss.org&gt; > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev(a)lists.jboss.org > Message-ID: > <JIRA.12562481.1423130482000.45725.1423150489341(a)Atlassian.JIRA&gt; > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... > ] > > John Ament commented on CDI-504: > -------------------------------- > > A separate config JSR has been proposed previously to address this. They > want to see more options before trying to standardize it. > > > have a standard CDI annotation like @ConfigProperty from deltapsike > > ------------------------------------------------------------------- > > > > Key: CDI-504 > > URL: https://issues.jboss.org/browse/CDI-504 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: James Strachan > > > > Docker and containerisation is the new hotness; in the docker world > > images are static and the main way of injecting configuration is via > > environment variables - so that the same image can be reused but configured > > at run time with different configuration values. (Changing configuration > > files requires either different images to be created or using custom volumes > > which is less ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to > > provide a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of > > the CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should > > win if the same name is used for both; in a dockerized world I'd prefer env > > vars to win but folks can always tinker with their run command to make sure > > they pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > Message: 4 > Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST) > From: "James Strachan (JIRA)" <issues(a)jboss.org&gt; > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev(a)lists.jboss.org > Message-ID: > <JIRA.12562481.1423130482000.45741.1423150789541(a)Atlassian.JIRA&gt; > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... > ] > > James Strachan commented on CDI-504: > ------------------------------------ > > @Resource is supported - injecting values from JNDI. I don't see why > injecting values (with a default value) from the environment isn't also > supported too. There's a Java API for JNDI too so folks could look stuff up > in JNDI by hand and do the type conversions - but we've injection for those > values. > > Its also much cleaner code and can easily deal generically with type > conversion to long/double/float/date etc. > > Compare: > {code} > @Inject Foo(int bar, ...) { > bar = System.getenv("FOO"); > if (bar == null) { > bar = "someDefault"; > } > // now convert to a String with error handling.... > } > {code} > to just: > {code} > @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > } > {code} > > Also by using an annotation it means its very easy to generate > documentation and tooling. (e.g. using APT you can know what all the > environment variables are used by CDI; either to report on demand or to > generate user documentation). > > > > > have a standard CDI annotation like @ConfigProperty from deltapsike > > ------------------------------------------------------------------- > > > > Key: CDI-504 > > URL: https://issues.jboss.org/browse/CDI-504 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: James Strachan > > > > Docker and containerisation is the new hotness; in the docker world > > images are static and the main way of injecting configuration is via > > environment variables - so that the same image can be reused but configured > > at run time with different configuration values. (Changing configuration > > files requires either different images to be created or using custom volumes > > which is less ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to > > provide a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of > > the CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should > > win if the same name is used for both; in a dockerized world I'd prefer env > > vars to win but folks can always tinker with their run command to make sure > > they pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > Message: 5 > Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST) > From: "James Strachan (JIRA)" <issues(a)jboss.org&gt; > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev(a)lists.jboss.org > Message-ID: > <JIRA.12562481.1423130482000.45763.1423151389408(a)Atlassian.JIRA&gt; > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... > ] > > James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM: > ------------------------------------------------------------- > > @Resource is supported - injecting values from JNDI. I don't see why > injecting values (with a default value) from the environment isn't also > supported too. There's a Java API for JNDI too so folks could look stuff up > in JNDI by hand and do the type conversions - but we've injection for those > values. > > Its also much cleaner code and can easily deal generically with type > conversion to long/double/float/date etc. > > Compare: > {code} > @Inject Foo(int bar, ...) { > bar = System.getenv("FOO"); > if (bar == null) { > bar = "someDefault"; > } > // now convert the String to an int with nice error handling and > reporting.... > } > {code} > to just: > {code} > @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > } > {code} > > Also by using an annotation it means its very easy to generate > documentation and tooling. (e.g. using APT you can know what all the > environment variables are used by CDI; either to report on demand or to > generate user documentation). > > > > > was (Author: jastrachan): > @Resource is supported - injecting values from JNDI. I don't see why > injecting values (with a default value) from the environment isn't also > supported too. There's a Java API for JNDI too so folks could look stuff up > in JNDI by hand and do the type conversions - but we've injection for those > values. > > Its also much cleaner code and can easily deal generically with type > conversion to long/double/float/date etc. > > Compare: > {code} > @Inject Foo(int bar, ...) { > bar = System.getenv("FOO"); > if (bar == null) { > bar = "someDefault"; > } > // now convert to a String with error handling.... > } > {code} > to just: > {code} > @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > } > {code} > > Also by using an annotation it means its very easy to generate > documentation and tooling. (e.g. using APT you can know what all the > environment variables are used by CDI; either to report on demand or to > generate user documentation). > > > > > have a standard CDI annotation like @ConfigProperty from deltapsike > > ------------------------------------------------------------------- > > > > Key: CDI-504 > > URL: https://issues.jboss.org/browse/CDI-504 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: James Strachan > > > > Docker and containerisation is the new hotness; in the docker world > > images are static and the main way of injecting configuration is via > > environment variables - so that the same image can be reused but configured > > at run time with different configuration values. (Changing configuration > > files requires either different images to be created or using custom volumes > > which is less ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to > > provide a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of > > the CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should > > win if the same name is used for both; in a dockerized world I'd prefer env > > vars to win but folks can always tinker with their run command to make sure > > they pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > Message: 6 > Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST) > From: "James Strachan (JIRA)" <issues(a)jboss.org&gt; > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev(a)lists.jboss.org > Message-ID: > <JIRA.12562481.1423130482000.45773.1423151449139(a)Atlassian.JIRA&gt; > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... > ] > > James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM: > ------------------------------------------------------------- > > @Resource is supported - injecting values from JNDI. I don't see why > injecting values (with a default value) from the environment isn't also > supported too. There's a Java API for JNDI too so folks could look stuff up > in JNDI by hand and do the type conversions - but we've injection for those > values. > > Its also much cleaner code and can easily deal generically with type > conversion to long/double/float/date etc. > > Compare: > {code} > int bar; > @Inject Foo() { > barText = System.getenv("FOO"); > if (barText == null) { > barText = "someDefault"; > } > // now convert the String to an int with nice error handling and > reporting.... > bar = someConvertCode(barText); > } > {code} > to just: > {code} > @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > } > {code} > > Note that in the second case, folks could use the constructor explicitly > without being bound to environment variables too; much cleaner, more modular > code. > > Also by using an annotation it means its very easy to generate > documentation and tooling. (e.g. using APT you can know what all the > environment variables are used by CDI; either to report on demand or to > generate user documentation). > > > > > was (Author: jastrachan): > @Resource is supported - injecting values from JNDI. I don't see why > injecting values (with a default value) from the environment isn't also > supported too. There's a Java API for JNDI too so folks could look stuff up > in JNDI by hand and do the type conversions - but we've injection for those > values. > > Its also much cleaner code and can easily deal generically with type > conversion to long/double/float/date etc. > > Compare: > {code} > @Inject Foo(int bar, ...) { > bar = System.getenv("FOO"); > if (bar == null) { > bar = "someDefault"; > } > // now convert the String to an int with nice error handling and > reporting.... > } > {code} > to just: > {code} > @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > } > {code} > > Also by using an annotation it means its very easy to generate > documentation and tooling. (e.g. using APT you can know what all the > environment variables are used by CDI; either to report on demand or to > generate user documentation). > > > > > have a standard CDI annotation like @ConfigProperty from deltapsike > > ------------------------------------------------------------------- > > > > Key: CDI-504 > > URL: https://issues.jboss.org/browse/CDI-504 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: James Strachan > > > > Docker and containerisation is the new hotness; in the docker world > > images are static and the main way of injecting configuration is via > > environment variables - so that the same image can be reused but configured > > at run time with different configuration values. (Changing configuration > > files requires either different images to be created or using custom volumes > > which is less ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to > > provide a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of > > the CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should > > win if the same name is used for both; in a dockerized world I'd prefer env > > vars to win but folks can always tinker with their run command to make sure > > they pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > Message: 7 > Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST) > From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org&gt; > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev(a)lists.jboss.org > Message-ID: > <JIRA.12562481.1423130482000.47108.1423216969246(a)Atlassian.JIRA&gt; > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... > ] > > Antoine Sabot-Durand commented on CDI-504: > ------------------------------------------ > > James, I don't get what's the problem with using DeltaSpike config > solution? > > > have a standard CDI annotation like @ConfigProperty from deltapsike > > ------------------------------------------------------------------- > > > > Key: CDI-504 > > URL: https://issues.jboss.org/browse/CDI-504 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: James Strachan > > > > Docker and containerisation is the new hotness; in the docker world > > images are static and the main way of injecting configuration is via > > environment variables - so that the same image can be reused but configured > > at run time with different configuration values. (Changing configuration > > files requires either different images to be created or using custom volumes > > which is less ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to > > provide a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of > > the CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should > > win if the same name is used for both; in a dockerized world I'd prefer env > > vars to win but folks can always tinker with their run command to make sure > > they pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)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 51, Issue 9 > ************************************** _______________________________________________ cdi-dev mailing list cdi-dev(a)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.