Re: [cdi-dev] cdi-dev Digest, Vol 51, Issue 12
by Werner Keil
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(a)lists.jboss.org> 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. 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>
> 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>
> 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>
> Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> annotation like
> To: arjan tijms <arjan.tijms(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAAGawe3_v086e6LYG8mh6burZOm+P+FyS4XS2BJ-TrfA+ELvXQ(a)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(a)gmail.com> wrote:
>
> > Hi,
> >
> > On Fri, Feb 6, 2015 at 11:22 AM, Werner Keil <werner.keil(a)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(a)lists.jboss.org>
> > 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>
> > >> 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>
> > >> 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>
> > >> 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>
> > >> 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>
> > >> 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>
> > >> 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>
> > >> 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
> ***************************************
>
9 years, 2 months
- 1
- 0
Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like
by Werner Keil
James,
I agree with Antoine as IMHO this would exceed the scope of core CDI a bit.
There was a discussion by Anatole Tresch (also member of this EG) about
creating a dedicated Configuration JSR (modeled among others also a lot
after what DeltaSpike does) but so far JCP officials first and foremost
Oracle saw either no need or no resources to do this.
Apache Tamaya was a logical result. If that could become a blue-print or
initial contribution of a future JSR, let's see, maybe for EE 9. It uses
other Apache projects like DeltaSpike where applicable, but may also define
such annotations and types of its own, so I suggest you also share your
ideas on a Tamaya mailing list or JIRA:
http://tamaya.incubator.apache.org/index.html
On Fri, Feb 6, 2015 at 11:02 AM, <cdi-dev-request(a)lists.jboss.org> 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>
> 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>
> 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>
> 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>
> 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>
> 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>
> 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>
> 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
> **************************************
>
9 years, 2 months
- 3
- 2
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by James Strachan (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
James Strachan commented on CDI-504:
------------------------------------
@Antoine yeah - there's nothing wrong with deltaspike - I just feel it'd be nice for folks to just depend on the standard CDI APIs and jars and for env vars to be supported in all CDI environments
> 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)
9 years, 2 months
- 1
- 0
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-504:
-------------------------------
This seems like a pretty good idea to me. Environment variables are part of Java since the beginning, and so we are adding something based on a very well specified area. This would have a lot of utility in the docker/microservice/devops view of the world, for very little cost.
The reason not to use DS is to be able to depend on this everywhere, with no library. The reason to not just do producers is to make this globally available.
> 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)
9 years, 2 months
- 1
- 0
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Antoine Sabot-Durand (JIRA)
[ 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)
9 years, 2 months
- 1
- 0
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by James Strachan (JIRA)
[ 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)
9 years, 2 months
- 1
- 0
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by James Strachan (JIRA)
[ 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)
9 years, 2 months
- 1
- 0
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by James Strachan (JIRA)
[ 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)
9 years, 2 months
- 1
- 0
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by John Ament (JIRA)
[ 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)
9 years, 2 months
- 1
- 0
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Martin Kouba (JIRA)
[ 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)
9 years, 2 months
- 1
- 0