[cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like
arjan tijms
arjan.tijms at gmail.com
Fri Feb 6 07:23:14 EST 2015
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.
More information about the cdi-dev
mailing list