[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Antonio Goncalves commented on CDI-504:
---------------------------------------
Like [~meetoblivion] said, a Config JSR was planned for Java EE 8. It has been postponed (hopefully for EE 9). I don't think it's a good idea to add standard configuration capabilities to CDI.
> 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)
10 years, 1 month
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba edited comment on CDI-504 at 2/9/15 4:26 AM:
----------------------------------------------------------
{quote}
* @Env...
{quote}
+1 for omitting Property, it's an environment variable anyway.
{quote}
* conversion should be defined on a close set of types...
{quote}
+1, primitives + wrappers + java.lang.String might be enough.
was (Author: mkouba):
{quote}
* @Env...
{quote}
+1 for omitting Property, it's an environment variable anyway.
{quote}
* conversion should be defined on a close set of types (primitives, wrapper + few java.lang/java.util + Collection + Map only) to ensure portability - not sure it is matre enough to support a good SPI ATM and if then it shouldnt be in config spec tamaya tries to prepare.
{quote}
+1, primitives + wrappers + java.lang.String might be enough.
> 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)
10 years, 1 month
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-504:
----------------------------------
{quote}
* @Env...
{quote}
+1 for omitting Property, it's an environment variable anyway.
{quote}
* conversion should be defined on a close set of types (primitives, wrapper + few java.lang/java.util + Collection + Map only) to ensure portability - not sure it is matre enough to support a good SPI ATM and if then it shouldnt be in config spec tamaya tries to prepare.
{quote}
+1, primitives + wrappers + java.lang.String might be enough.
> 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)
10 years, 1 month
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau edited comment on CDI-504 at 2/9/15 4:17 AM:
----------------------------------------------------------------
+1 with few minors notes:
- @Env and @SystemProperty maybe (instead of EnvProperty) to match JVM naming (@Property would be less meaningful IMO)
- conversion should be defined on a close set of types (primitives, wrapper + few java.lang/java.util + Collection + Map only) to ensure portability - not sure it is matre enough to support a good SPI ATM and if then it shouldnt be in config spec tamaya tries to prepare.
wdyt?
was (Author: rmannibucau):
+1 with few (minors notes):
- @Env and @SystemProperty maybe (instead of EnvProperty) to match JVM naming (@Property would be less meaningful IMO)
- conversion should be defined on a close set of types (primitives, wrapper + few java.lang/java.util + Collection + Map only) to ensure portability - not sure it is matre enough to support a good SPI ATM and if then it shouldnt be in config spec tamaya tries to prepare.
wdyt?
> 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)
10 years, 1 month
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-504:
----------------------------------------
+1 with few (minors notes):
- @Env and @SystemProperty maybe (instead of EnvProperty) to match JVM naming (@Property would be less meaningful IMO)
- conversion should be defined on a close set of types (primitives, wrapper + few java.lang/java.util + Collection + Map only) to ensure portability - not sure it is matre enough to support a good SPI ATM and if then it shouldnt be in config spec tamaya tries to prepare.
wdyt?
> 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)
10 years, 1 month
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-504:
-------------------------------
I would prefer {{@EnvironmentProperty}} :-)
This one is the important one, {{@System Property}} may be added for completeness.
> 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)
10 years, 1 month
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-504:
----------------------------------
[~jastrachan] [~pmuir] [~antoinesabot-durand] The out of box conversion and global availability convinced me :-). So there would be {{@EnvProperty}} and {{@SystemProperty}} and if a user wants more, there is the DS Configuration...?
> 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)
10 years, 1 month
[JBoss JIRA] (CDI-505) Clarification on getInvokedBusinessInterfact() with conflicting throws clause
by Emily Jiang (JIRA)
Emily Jiang created CDI-505:
-------------------------------
Summary: Clarification on getInvokedBusinessInterfact() with conflicting throws clause
Key: CDI-505
URL: https://issues.jboss.org/browse/CDI-505
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.2.Final
Environment: n/a
Reporter: Emily Jiang
Priority: Minor
In the CDI 1.2 spec, it states:
When a contextual instance of a session bean is obtained via the dependency injection service,the behavior of SessionContext.getInvokedBusinessInterface() is specific to the container
implementation. Portable applications should not rely upon the value returned by this method.
However, it needs to specify what should happen when an EJB has multiple interfaces with conflicting throws clauses for the same method. The preferred outcome would be that CDI mandates getInvokedBusinessInterface and conflicting throws clauses work as expected.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 1 month
Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like
by Tresch, Anatole
Hi James
I follow also Antoine and Werner that it makes no sense to just add an annotation due to the reason, that adding such an annotation it would requires also to define the exact functionality. This has severe downsides, or basically is not possible within the CDI scope since:
· there are many different views, what such an annotation should do
· if you interpret it widely (and flexible, which makes sense looking at the variety of possible use cases/requirements), you will end up in a complete additional kind of configuration “sub-spec”,which would bloat the CDI spec. This is also not necessary, since we can do everything we want without any additions to CDI. Even configuring CDI is no issues, since the SPI (extensions) are so incredibly flexible ;)
· if you define the semantics more constraint, e.g. as suggested (system and env properties), it would render the annotation quite useless, for a lot of legit use cases can not be covered. And even with these env / sys properties many questions are still open (like overriding order, overriding policies to mentions some), which are definitively out of scope for CDI as spec.
Looking at Apache Tamaya (http://tamaya.incubator.apache.org ), where I together with some other guys (including Mark and Gerhard from Deltaspike) are trying to define a common, minimalistic, but extensible API/SPI, I think we have all the ingredients for a future and unified approach for this topic. We can with the couple of API artifacts we have defined (e.g. see https://github.com/apache/incubator-tamaya/blob/master/docs/API.adoc ), cover everything, what Deltaspike can do for you today, but also the most complex requirements I am aware of, basically fit into this simple approach there. So I would like to encourage you to join our Apache Project and help to drive Apache Tamaya, so we can increase adoption quickly and then hopefully get enough momentum to make it a JSR.
Cheers,
Anatole
---------- Forwarded message ---------
From: Werner Keil <werner.keil(a)gmail.com<mailto:werner.keil@gmail.com>>
Date: Fr., 6. Feb. 2015 um 11:22
Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like
To: cdi-dev <cdi-dev(a)lists.jboss.org<mailto:cdi-dev@lists.jboss.org>>
James,
I agree with Antoine as IMHO this would exceed the scope of core CDI a bit.
There was a discussion by Anatole Tresch (also member of this EG) about creating a dedicated Configuration JSR (modeled among others also a lot after what DeltaSpike does) but so far JCP officials first and foremost Oracle saw either no need or no resources to do this.
Apache Tamaya was a logical result. If that could become a blue-print or initial contribution of a future JSR, let's see, maybe for EE 9. It uses other Apache projects like DeltaSpike where applicable, but may also define such annotations and types of its own, so I suggest you also share your ideas on a Tamaya mailing list or JIRA: http://tamaya.incubator.apache.org/index.html
On Fri, Feb 6, 2015 at 11:02 AM, <cdi-dev-request(a)lists.jboss.org<mailto:cdi-dev-request@lists.jboss.org>> wrote:
Send cdi-dev mailing list submissions to
cdi-dev(a)lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
cdi-dev-request(a)lists.jboss.org<mailto:cdi-dev-request@lists.jboss.org>
You can reach the person managing the list at
cdi-dev-owner(a)lists.jboss.org<mailto:cdi-dev-owner@lists.jboss.org>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."
Today's Topics:
1. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (James Strachan (JIRA))
2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (Martin Kouba (JIRA))
3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (John Ament (JIRA))
4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (James Strachan (JIRA))
5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (James Strachan (JIRA))
6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (James Strachan (JIRA))
7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA))
----------------------------------------------------------------------
Message: 1
Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST)
From: "James Strachan (JIRA)" <issues(a)jboss.org<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12562481.1423130482000.44616.1423130509034(a)Atlassian.JIRA<mailto:JIRA.12562481.1423130482000.44616.1423130509034@Atlassian.JIRA>>
Content-Type: text/plain; charset=UTF-8
James Strachan created CDI-504:
----------------------------------
Summary: have a standard CDI annotation like @ConfigProperty from deltapsike
Key: CDI-504
URL: https://issues.jboss.org/browse/CDI-504
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: James Strachan
Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
Delta Spike as a @ConfigProperty annotation which works very nicely
http://deltaspike.apache.org/documentation/configuration.html
you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
Message: 2
Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST)
From: "Martin Kouba (JIRA)" <issues(a)jboss.org<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12562481.1423130482000.45712.1423150250888(a)Atlassian.JIRA<mailto:JIRA.12562481.1423130482000.45712.1423150250888@Atlassian.JIRA>>
Content-Type: text/plain; charset=UTF-8
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-504:
----------------------------------
What's wrong with {{java.lang.System.getProperty()}} and {{java.lang.System.getenv()}}? I mean the main advantage of DS Configuration is IMO the resolution mechanism and the ability to extend the set of {{ConfigSource}} s. If you only need system properties and env variables a simple producer method and qualifier (or even a simple util method) would be sufficient. In other words I see no reason to standardize this.
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
Message: 3
Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST)
From: "John Ament (JIRA)" <issues(a)jboss.org<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12562481.1423130482000.45725.1423150489341(a)Atlassian.JIRA<mailto:JIRA.12562481.1423130482000.45725.1423150489341@Atlassian.JIRA>>
Content-Type: text/plain; charset=UTF-8
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-504:
--------------------------------
A separate config JSR has been proposed previously to address this. They want to see more options before trying to standardize it.
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
Message: 4
Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST)
From: "James Strachan (JIRA)" <issues(a)jboss.org<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12562481.1423130482000.45741.1423150789541(a)Atlassian.JIRA<mailto:JIRA.12562481.1423130482000.45741.1423150789541@Atlassian.JIRA>>
Content-Type: text/plain; charset=UTF-8
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
James Strachan commented on CDI-504:
------------------------------------
@Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values.
Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc.
Compare:
{code}
@Inject Foo(int bar, ...) {
bar = System.getenv("FOO");
if (bar == null) {
bar = "someDefault";
}
// now convert to a String with error handling....
}
{code}
to just:
{code}
@Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
}
{code}
Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation).
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
Message: 5
Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST)
From: "James Strachan (JIRA)" <issues(a)jboss.org<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12562481.1423130482000.45763.1423151389408(a)Atlassian.JIRA<mailto:JIRA.12562481.1423130482000.45763.1423151389408@Atlassian.JIRA>>
Content-Type: text/plain; charset=UTF-8
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM:
-------------------------------------------------------------
@Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values.
Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc.
Compare:
{code}
@Inject Foo(int bar, ...) {
bar = System.getenv("FOO");
if (bar == null) {
bar = "someDefault";
}
// now convert the String to an int with nice error handling and reporting....
}
{code}
to just:
{code}
@Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
}
{code}
Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation).
was (Author: jastrachan):
@Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values.
Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc.
Compare:
{code}
@Inject Foo(int bar, ...) {
bar = System.getenv("FOO");
if (bar == null) {
bar = "someDefault";
}
// now convert to a String with error handling....
}
{code}
to just:
{code}
@Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
}
{code}
Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation).
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
Message: 6
Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST)
From: "James Strachan (JIRA)" <issues(a)jboss.org<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12562481.1423130482000.45773.1423151449139(a)Atlassian.JIRA<mailto:JIRA.12562481.1423130482000.45773.1423151449139@Atlassian.JIRA>>
Content-Type: text/plain; charset=UTF-8
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM:
-------------------------------------------------------------
@Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values.
Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc.
Compare:
{code}
int bar;
@Inject Foo() {
barText = System.getenv("FOO");
if (barText == null) {
barText = "someDefault";
}
// now convert the String to an int with nice error handling and reporting....
bar = someConvertCode(barText);
}
{code}
to just:
{code}
@Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
}
{code}
Note that in the second case, folks could use the constructor explicitly without being bound to environment variables too; much cleaner, more modular code.
Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation).
was (Author: jastrachan):
@Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values.
Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc.
Compare:
{code}
@Inject Foo(int bar, ...) {
bar = System.getenv("FOO");
if (bar == null) {
bar = "someDefault";
}
// now convert the String to an int with nice error handling and reporting....
}
{code}
to just:
{code}
@Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
}
{code}
Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation).
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
Message: 7
Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST)
From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12562481.1423130482000.47108.1423216969246(a)Atlassian.JIRA<mailto:JIRA.12562481.1423130482000.47108.1423216969246@Atlassian.JIRA>>
Content-Type: text/plain; charset=UTF-8
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-504:
------------------------------------------
James, I don't get what's the problem with using DeltaSpike config solution?
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
End of cdi-dev Digest, Vol 51, Issue 9
**************************************
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org<mailto:cdi-dev@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.
10 years, 1 month
