[cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like
Mark Struberg
struberg at yahoo.de
Mon Feb 9 04:51:12 EST 2015
>>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 at 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 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.
>>
>
>_______________________________________________
>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