Re: [cdi-dev] cdi-dev Digest, Vol 51, Issue 12

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. Re: [JBoss JIRA] (CDI-504) have a standard CDI annotation like (Antoine Sabot-Durand) 2. Re: [JBoss JIRA] (CDI-504) have a standard CDI annotation like (Werner Keil) ---------------------------------------------------------------------- Message: 1 Date: Fri, 6 Feb 2015 05:33:06 -0700 (MST) From: Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like To: cdi-dev(a)lists.jboss.org Message-ID: <1423225986023-5710923.post(a)n5.nabble.com&gt; Content-Type: text/plain; charset=us-ascii Werner, It would be better to answer Jira discussion on Jira to keep information on the ticket. Antoine -- View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Re-JBoss-JIRA-C... Sent from the CDI Development mailing list mailing list archive at Nabble.com. ------------------------------ Message: 2 Date: Fri, 6 Feb 2015 13:33:36 +0100 From: Werner Keil <werner.keil(a)gmail.com&gt; Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like To: arjan tijms <arjan.tijms(a)gmail.com&gt; Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Message-ID: < CAAGawe3_v086e6LYG8mh6burZOm+P+FyS4XS2BJ-TrfA+ELvXQ(a)mail.gmail.com&gt; Content-Type: text/plain; charset="utf-8" If DeltaSpike Configuration already covered everything there would have been no need for Tamaya;-) On Fri, Feb 6, 2015 at 1:23 PM, arjan tijms <arjan.tijms(a)gmail.com&gt; wrote: > Hi, > > On Fri, Feb 6, 2015 at 11:22 AM, Werner Keil <werner.keil(a)gmail.com&gt; > wrote: > > but so far JCP officials first and foremost > > Oracle saw either no need or no resources to do this. > > I remember some other issues being on the table, like Java SE vs Java > EE and "configuring the runtime" vs "injecting/providing values to the > app". > > DeltaSpike Configuration is really great, but it's a value provider. > It doesn't let you swap out or overlay deployment descriptors etc. > > Kind regards, > Arjan Tijms > > > > > > > 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 > > > >> 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 > > > >> 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 > > > >> 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 > > > >> 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 > > > >> 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 > > > >> 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 > > > >> 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150206/bb2c4eaa/at... ------------------------------ _______________________________________________ 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 12 ***************************************