[cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like
Werner Keil
werner.keil at gmail.com
Fri Feb 6 07:33:36 EST 2015
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-0001.html
More information about the cdi-dev
mailing list