[cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like
John D. Ament
john.d.ament at gmail.com
Mon Feb 9 08:18:49 EST 2015
I think everything you're describing are proposed pieces of the original
config JSR. CDI shouldn't have any business in doing things like allowing
the servlet spec to conditionally register a servlet.
John
On Mon Feb 09 2015 at 8:09:04 AM arjan tijms <arjan.tijms at gmail.com> wrote:
> 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.
> >>
> >>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150209/6ceac598/attachment-0001.html
More information about the cdi-dev
mailing list