[cdi-dev] cdi-dev Digest, Vol 51, Issue 12
Werner Keil
werner.keil at gmail.com
Fri Feb 6 07:36:10 EST 2015
How did it come here in the first place is there some automated mirror from
the JIRA tickets?;-)
I should have a JIRA user from Agorava, so I may use it there.
On Fri, Feb 6, 2015 at 1:33 PM, <cdi-dev-request at lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [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 at sabot-durand.net>
> Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> annotation like
> To: cdi-dev at lists.jboss.org
> Message-ID: <1423225986023-5710923.post at n5.nabble.com>
> 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-CDI-504-have-a-standard-CDI-annotation-like-tp5710919p5710923.html
> 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 at gmail.com>
> Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> annotation like
> To: arjan tijms <arjan.tijms at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <
> CAAGawe3_v086e6LYG8mh6burZOm+P+FyS4XS2BJ-TrfA+ELvXQ at mail.gmail.com>
> 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 at gmail.com> wrote:
>
> > Hi,
> >
> > On Fri, Feb 6, 2015 at 11:22 AM, Werner Keil <werner.keil at gmail.com>
> > 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 at lists.jboss.org>
> > wrote:
> > >>
> > >> Send cdi-dev mailing list submissions to
> > >> cdi-dev at lists.jboss.org
> > >>
> > >> To subscribe or unsubscribe via the World Wide Web, visit
> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >> or, via email, send a message with subject or body 'help' to
> > >> cdi-dev-request at lists.jboss.org
> > >>
> > >> You can reach the person managing the list at
> > >> cdi-dev-owner at lists.jboss.org
> > >>
> > >> When replying, please edit your Subject line so it is more specific
> > >> than "Re: Contents of cdi-dev digest..."
> > >>
> > >>
> > >> Today's Topics:
> > >>
> > >> 1. [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 at jboss.org>
> > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> > >> annotation like @ConfigProperty from deltapsike
> > >> To: cdi-dev at lists.jboss.org
> > >> Message-ID:
> > >>
> <JIRA.12562481.1423130482000.44616.1423130509034 at 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 at jboss.org>
> > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> > >> annotation like @ConfigProperty from deltapsike
> > >> To: cdi-dev at lists.jboss.org
> > >> Message-ID:
> > >>
> <JIRA.12562481.1423130482000.45712.1423150250888 at Atlassian.JIRA
> > >
> > >> Content-Type: text/plain; charset=UTF-8
> > >>
> > >>
> > >> [
> > >>
> >
> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038005#comment-13038005
> > >> ]
> > >>
> > >> 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 at jboss.org>
> > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> > >> annotation like @ConfigProperty from deltapsike
> > >> To: cdi-dev at lists.jboss.org
> > >> Message-ID:
> > >>
> <JIRA.12562481.1423130482000.45725.1423150489341 at Atlassian.JIRA
> > >
> > >> Content-Type: text/plain; charset=UTF-8
> > >>
> > >>
> > >> [
> > >>
> >
> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038007#comment-13038007
> > >> ]
> > >>
> > >> 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 at jboss.org>
> > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> > >> annotation like @ConfigProperty from deltapsike
> > >> To: cdi-dev at lists.jboss.org
> > >> Message-ID:
> > >>
> <JIRA.12562481.1423130482000.45741.1423150789541 at Atlassian.JIRA
> > >
> > >> Content-Type: text/plain; charset=UTF-8
> > >>
> > >>
> > >> [
> > >>
> >
> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012
> > >> ]
> > >>
> > >> 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 at jboss.org>
> > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> > >> annotation like @ConfigProperty from deltapsike
> > >> To: cdi-dev at lists.jboss.org
> > >> Message-ID:
> > >>
> <JIRA.12562481.1423130482000.45763.1423151389408 at Atlassian.JIRA
> > >
> > >> Content-Type: text/plain; charset=UTF-8
> > >>
> > >>
> > >> [
> > >>
> >
> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012
> > >> ]
> > >>
> > >> 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 at jboss.org>
> > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> > >> annotation like @ConfigProperty from deltapsike
> > >> To: cdi-dev at lists.jboss.org
> > >> Message-ID:
> > >>
> <JIRA.12562481.1423130482000.45773.1423151449139 at Atlassian.JIRA
> > >
> > >> Content-Type: text/plain; charset=UTF-8
> > >>
> > >>
> > >> [
> > >>
> >
> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012
> > >> ]
> > >>
> > >> 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 at jboss.org>
> > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> > >> annotation like @ConfigProperty from deltapsike
> > >> To: cdi-dev at lists.jboss.org
> > >> Message-ID:
> > >>
> <JIRA.12562481.1423130482000.47108.1423216969246 at Atlassian.JIRA
> > >
> > >> Content-Type: text/plain; charset=UTF-8
> > >>
> > >>
> > >> [
> > >>
> >
> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038271#comment-13038271
> > >> ]
> > >>
> > >> 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 at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >>
> > >> Note that for all code provided on this list, the provider licenses
> the
> > >> code under the Apache License, Version 2
> > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
> ideas
> > >> provided on this list, the provider waives all patent and other
> > intellectual
> > >> property rights inherent in such information.
> > >>
> > >> End of cdi-dev Digest, Vol 51, Issue 9
> > >> **************************************
> > >
> > >
> > >
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > > Note that for all code provided on this list, the provider licenses the
> > code
> > > under the Apache License, Version 2
> > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > > provided on this list, the provider waives all patent and other
> > intellectual
> > > property rights inherent in such information.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150206/bb2c4eaa/attachment.html
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 51, Issue 12
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150206/1e7423d5/attachment-0001.html
More information about the cdi-dev
mailing list