[cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like
arjan tijms
arjan.tijms at gmail.com
Mon Feb 9 08:08:47 EST 2015
Hi,
On Mon, Feb 9, 2015 at 10:51 AM, Mark Struberg <struberg at yahoo.de> wrote:
> Just curious: What is the need for swapping out overlay XMLs?
There are many usecases, but one of them it having an extra Servlet in
a few stages (say dev and beta) that gives tools special access to the
application, or a dev filter that provides some extra options for
development.
Yet another case is swapping out the data-source element in say
application.xml with different versions for each stage.
> When do you do the replacement? At deploy time? At runtime?
Most deployment descriptors are processed at deploy time, so when
starting up the application. You specify say a -D parameter when
starting up your server that specifies the stage of your server. The
runtime then chooses an overlay (e.g. extra XML fragment) based on the
value of the stage.
>What about reconfiguration? Does it need a redeploy?
The simplest case typically needs a redeploy indeed. Taking the
example with the Servlets; the Servlet API only lets you add and
remove Servlets and Filters during startup of the application.
> 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 might have been a no-go for your particular use case, but it's not
in general. It's extremely rare that you need to change the stage of a
running server. Frankly, in well over 10 years of designing, coding
and operating Java EE systems of various sizes, I don't think I've
ever encountered this.
> It also barely make sense in a time where most specs got completely rid of XML configs.
Wishful thinking if you'd ask me. While we surely go to more defaults
and not *requiring* any upfront XML config if the user is satisfied
with those defaults, Java EE is still firmly rooted in XML config.
Quite a lot of configuration scenarios are contextual and not
naturally expressibly in key/value pairs. I can speak for the JSF EG,
and at least in JSF there is no moving to anything other than XML
config (we have in fact discussed this). I'm not aware of anything in
the Servlet EG either. Things like a Filter definition with their
nested init params or security constraints etc are just not that
naturally expressed as key/value pairs. JSON perhaps, but not
key/value.
I strongly believe there are two main aspects of configuration that
should not be confused:
1. Configuring the container
2. Configuring the application
Where configuring is a matter of:
1. Overlaying XML fragments (in practice mostly a relatively simply
matter of choosing which fragment to include or not)
2. Providing EL or EL-like placeholders in XML and annotations
3. Providing key/values (and injecting them info the application)
Both the container itself and the application can theoretically take
advantage of any of these options, but it practice it seems the
container configuration leans more towards 1, while the application
leans more towards 3.
I felt that the Java EE configuration JSR, now Tamaya, largely
focussed on providing key/values and a means of injecting them into
the application, and didn't think at all about deployment descriptors
and placeholders in them.
Kind regards,
Arjan Tijms
>
>
>
>> 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