<div dir="ltr">How did it come here in the first place is there some automated mirror from the JIRA tickets?;-)<div class="gmail_extra">I should have a JIRA user from Agorava, so I may use it there.<span lang="EN-GB"><div style="font-family:arial,helvetica,sans-serif"><br></div></span>
<br><div class="gmail_quote">On Fri, Feb 6, 2015 at 1:33 PM, <span dir="ltr"><<a href="mailto:cdi-dev-request@lists.jboss.org" target="_blank">cdi-dev-request@lists.jboss.org</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">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. Re: [JBoss JIRA] (CDI-504) have a standard CDI annotation<br>
like (Antoine Sabot-Durand)<br>
2. Re: [JBoss JIRA] (CDI-504) have a standard CDI annotation<br>
like (Werner Keil)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 6 Feb 2015 05:33:06 -0700 (MST)<br>
From: Antoine Sabot-Durand <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>><br>
Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
annotation like<br>
To: <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
Message-ID: <<a href="mailto:1423225986023-5710923.post@n5.nabble.com">1423225986023-5710923.post@n5.nabble.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Werner, It would be better to answer Jira discussion on Jira to keep<br>
information on the ticket.<br>
<br>
Antoine<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://cdi-development-mailing-list.1064426.n5.nabble.com/Re-JBoss-JIRA-CDI-504-have-a-standard-CDI-annotation-like-tp5710919p5710923.html" target="_blank">http://cdi-development-mailing-list.1064426.n5.nabble.com/Re-JBoss-JIRA-CDI-504-have-a-standard-CDI-annotation-like-tp5710919p5710923.html</a><br>
Sent from the CDI Development mailing list mailing list archive at Nabble.com.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 6 Feb 2015 13:33:36 +0100<br>
From: Werner Keil <<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>><br>
Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
annotation like<br>
To: arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<<a href="mailto:CAAGawe3_v086e6LYG8mh6burZOm%2BP%2BFyS4XS2BJ-TrfA%2BELvXQ@mail.gmail.com">CAAGawe3_v086e6LYG8mh6burZOm+P+FyS4XS2BJ-TrfA+ELvXQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
If DeltaSpike Configuration already covered everything there would have<br>
been no need for Tamaya;-)<br>
<br>
On Fri, Feb 6, 2015 at 1:23 PM, arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> On Fri, Feb 6, 2015 at 11:22 AM, Werner Keil <<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>><br>
> wrote:<br>
> > but so far JCP officials first and foremost<br>
> > Oracle saw either no need or no resources to do this.<br>
><br>
> 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>
><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<br>
> 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>><br>
> 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>
> ><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<br>
> @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<br>
> images<br>
> >> are static and the main way of injecting configuration is via<br>
> environment<br>
> >> variables - so that the same image can be reused but configured at run<br>
> time<br>
> >> with different configuration values. (Changing configuration files<br>
> requires<br>
> >> either different images to be created or using custom volumes which is<br>
> 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<br>
> 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<br>
> 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<br>
> win<br>
> >> if the same name is used for both; in a dockerized world I'd prefer env<br>
> vars<br>
> >> to win but folks can always tinker with their run command to make sure<br>
> 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>
> ><br>
> >> Content-Type: text/plain; charset=UTF-8<br>
> >><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<br>
> 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<br>
> variables a<br>
> >> simple producer method and qualifier (or even a simple util method)<br>
> 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<br>
> configured<br>
> >> > at run time with different configuration values. (Changing<br>
> configuration<br>
> >> > files requires either different images to be created or using custom<br>
> 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<br>
> 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<br>
> prefer env<br>
> >> > vars to win but folks can always tinker with their run command to<br>
> make sure<br>
> >> > they pass in env vars as system properties to work around this I<br>
> 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>
> ><br>
> >> Content-Type: text/plain; charset=UTF-8<br>
> >><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.<br>
> 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<br>
> configured<br>
> >> > at run time with different configuration values. (Changing<br>
> configuration<br>
> >> > files requires either different images to be created or using custom<br>
> 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<br>
> 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<br>
> prefer env<br>
> >> > vars to win but folks can always tinker with their run command to<br>
> make sure<br>
> >> > they pass in env vars as system properties to work around this I<br>
> 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>
> ><br>
> >> Content-Type: text/plain; charset=UTF-8<br>
> >><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<br>
> stuff up<br>
> >> in JNDI by hand and do the type conversions - but we've injection for<br>
> 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<br>
> configured<br>
> >> > at run time with different configuration values. (Changing<br>
> configuration<br>
> >> > files requires either different images to be created or using custom<br>
> 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<br>
> 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<br>
> prefer env<br>
> >> > vars to win but folks can always tinker with their run command to<br>
> make sure<br>
> >> > they pass in env vars as system properties to work around this I<br>
> 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>
> ><br>
> >> Content-Type: text/plain; charset=UTF-8<br>
> >><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<br>
> stuff up<br>
> >> in JNDI by hand and do the type conversions - but we've injection for<br>
> 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<br>
> stuff up<br>
> >> in JNDI by hand and do the type conversions - but we've injection for<br>
> 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<br>
> configured<br>
> >> > at run time with different configuration values. (Changing<br>
> configuration<br>
> >> > files requires either different images to be created or using custom<br>
> 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<br>
> 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<br>
> prefer env<br>
> >> > vars to win but folks can always tinker with their run command to<br>
> make sure<br>
> >> > they pass in env vars as system properties to work around this I<br>
> 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>
> ><br>
> >> Content-Type: text/plain; charset=UTF-8<br>
> >><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<br>
> stuff up<br>
> >> in JNDI by hand and do the type conversions - but we've injection for<br>
> 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<br>
> 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<br>
> stuff up<br>
> >> in JNDI by hand and do the type conversions - but we've injection for<br>
> 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<br>
> configured<br>
> >> > at run time with different configuration values. (Changing<br>
> configuration<br>
> >> > files requires either different images to be created or using custom<br>
> 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<br>
> 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<br>
> prefer env<br>
> >> > vars to win but folks can always tinker with their run command to<br>
> make sure<br>
> >> > they pass in env vars as system properties to work around this I<br>
> 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>
> ><br>
> >> Content-Type: text/plain; charset=UTF-8<br>
> >><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<br>
> configured<br>
> >> > at run time with different configuration values. (Changing<br>
> configuration<br>
> >> > files requires either different images to be created or using custom<br>
> 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<br>
> 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<br>
> prefer env<br>
> >> > vars to win but folks can always tinker with their run command to<br>
> make sure<br>
> >> > they pass in env vars as system properties to work around this I<br>
> 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<br>
> 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<br>
> 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<br>
> intellectual<br>
> > property rights inherent in such information.<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20150206/bb2c4eaa/attachment.html" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20150206/bb2c4eaa/attachment.html</a><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 under the Apache License, Version 2 (<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 provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br>
End of cdi-dev Digest, Vol 51, Issue 12<br>
***************************************<br>
</blockquote></div><br></div></div>