>DeltaSpike Configuration is really great, but it's a value
provider.
>It doesn't let you swap out or overlay deployment descriptors etc.
Just curious: What is the need for swapping out overlay XMLs?
When do you do the replacement? At deploy time? At runtime? What about reconfiguration?
Does it need a redeploy? etc. I had to live with it in WebLogic in a project. And to me it
felt like it was pretty much broken as it did require a redeployment or at least a server
reboot to change the configuration. That's simply a no-go.
It also barely make sense in a time where most specs got completely rid of XML configs.
If DeltaSpike Configuration already covered everything
there would have been no need for Tamaya;-)
The main goal is to get a JSR running. If we don't achieve this then there is really
not that much benefit in Tamaya. But I am really hopeful that we DO get this done!
LieGrue,
strub
On Friday, 6 February 2015, 13:34, Werner Keil <werner.keil(a)gmail.com> wrote:
>
>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.
>>
>
>_______________________________________________
>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.
>
>