4:22 a.m.
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> wrote:
Send cdi-dev mailing list submissions to
cdi-dev(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
cdi-dev-request(a)lists.jboss.org
You can reach the person managing the list at
cdi-dev-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."
Today's Topics:
1. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (James Strachan (JIRA))
2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (Martin Kouba (JIRA))
3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (John Ament (JIRA))
4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (James Strachan (JIRA))
5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (James Strachan (JIRA))
6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (James Strachan (JIRA))
7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
@ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA))
----------------------------------------------------------------------
Message: 1
Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST)
From: "James Strachan (JIRA)" <issues(a)jboss.org>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org
Message-ID:
<JIRA.12562481.1423130482000.44616.1423130509034(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
James Strachan created CDI-504:
----------------------------------
Summary: have a standard CDI annotation like @ConfigProperty
from deltapsike
Key: CDI-504
URL: https://issues.jboss.org/browse/CDI-504
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: James Strachan
Docker and containerisation is the new hotness; in the docker world images
are static and the main way of injecting configuration is via environment
variables - so that the same image can be reused but configured at run time
with different configuration values. (Changing configuration files requires
either different images to be created or using custom volumes which is less
ideal in a containerized world).
So IMHO CDI should provide a simple, natural way to allow environment
variables (or system properties) to be easily injected via CDI.
Delta Spike as a @ConfigProperty annotation which works very nicely
http://deltaspike.apache.org/documentation/configuration.html
you can specify a name, default value and use it on an @Inject to provide
a value from env vars, system properties or provide a default.
Given how core and useful this is - it feels like it should be part of the
CDI specification; its one simple annotation.
Currently deltaspike provides a way to configure different sources and
whatnot which is cool; I'd be happy if CDI just had a simpler annotation
which was only bound to env vars / system properties.
e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
There could be debate on whether env vars or system properties should win
if the same name is used for both; in a dockerized world I'd prefer env
vars to win but folks can always tinker with their run command to make sure
they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
Message: 2
Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST)
From: "Martin Kouba (JIRA)" <issues(a)jboss.org>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org
Message-ID:
<JIRA.12562481.1423130482000.45712.1423150250888(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
[
https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy...
]
Martin Kouba commented on CDI-504:
----------------------------------
What's wrong with {{java.lang.System.getProperty()}} and
{{java.lang.System.getenv()}}? I mean the main advantage of DS
Configuration is IMO the resolution mechanism and the ability to extend the
set of {{ConfigSource}} s. If you only need system properties and env
variables a simple producer method and qualifier (or even a simple util
method) would be sufficient. In other words I see no reason to standardize
this.
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world
images are static and the main way of injecting configuration is via
environment variables - so that the same image can be reused but configured
at run time with different configuration values. (Changing configuration
files requires either different images to be created or using custom
volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment
variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to
provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of
the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and
whatnot which is cool; I'd be happy if CDI just had a simpler annotation
which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar",
deafultValue="cheese")
> There could be debate on whether env vars or system properties should
win if the same name is used for both; in a dockerized world I'd prefer env
vars to win but folks can always tinker with their run command to make sure
they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
Message: 3
Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST)
From: "John Ament (JIRA)" <issues(a)jboss.org>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org
Message-ID:
<JIRA.12562481.1423130482000.45725.1423150489341(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
[
https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy...
]
John Ament commented on CDI-504:
--------------------------------
A separate config JSR has been proposed previously to address this. They
want to see more options before trying to standardize it.
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world
images are static and the main way of injecting configuration is via
environment variables - so that the same image can be reused but configured
at run time with different configuration values. (Changing configuration
files requires either different images to be created or using custom
volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment
variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to
provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of
the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and
whatnot which is cool; I'd be happy if CDI just had a simpler annotation
which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar",
deafultValue="cheese")
> There could be debate on whether env vars or system properties should
win if the same name is used for both; in a dockerized world I'd prefer env
vars to win but folks can always tinker with their run command to make sure
they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
Message: 4
Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST)
From: "James Strachan (JIRA)" <issues(a)jboss.org>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org
Message-ID:
<JIRA.12562481.1423130482000.45741.1423150789541(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
[
https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy...
]
James Strachan commented on CDI-504:
------------------------------------
@Resource is supported - injecting values from JNDI. I don't see why
injecting values (with a default value) from the environment isn't also
supported too. There's a Java API for JNDI too so folks could look stuff up
in JNDI by hand and do the type conversions - but we've injection for those
values.
Its also much cleaner code and can easily deal generically with type
conversion to long/double/float/date etc.
Compare:
{code}
@Inject Foo(int bar, ...) {
bar = System.getenv("FOO");
if (bar == null) {
bar = "someDefault";
}
// now convert to a String with error handling....
}
{code}
to just:
{code}
@Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
}
{code}
Also by using an annotation it means its very easy to generate
documentation and tooling. (e.g. using APT you can know what all the
environment variables are used by CDI; either to report on demand or to
generate user documentation).
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world
images are static and the main way of injecting configuration is via
environment variables - so that the same image can be reused but configured
at run time with different configuration values. (Changing configuration
files requires either different images to be created or using custom
volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment
variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to
provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of
the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and
whatnot which is cool; I'd be happy if CDI just had a simpler annotation
which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar",
deafultValue="cheese")
> There could be debate on whether env vars or system properties should
win if the same name is used for both; in a dockerized world I'd prefer env
vars to win but folks can always tinker with their run command to make sure
they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
Message: 5
Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST)
From: "James Strachan (JIRA)" <issues(a)jboss.org>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org
Message-ID:
<JIRA.12562481.1423130482000.45763.1423151389408(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
[
https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy...
]
James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM:
-------------------------------------------------------------
@Resource is supported - injecting values from JNDI. I don't see why
injecting values (with a default value) from the environment isn't also
supported too. There's a Java API for JNDI too so folks could look stuff up
in JNDI by hand and do the type conversions - but we've injection for those
values.
Its also much cleaner code and can easily deal generically with type
conversion to long/double/float/date etc.
Compare:
{code}
@Inject Foo(int bar, ...) {
bar = System.getenv("FOO");
if (bar == null) {
bar = "someDefault";
}
// now convert the String to an int with nice error handling and
reporting....
}
{code}
to just:
{code}
@Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
}
{code}
Also by using an annotation it means its very easy to generate
documentation and tooling. (e.g. using APT you can know what all the
environment variables are used by CDI; either to report on demand or to
generate user documentation).
was (Author: jastrachan):
@Resource is supported - injecting values from JNDI. I don't see why
injecting values (with a default value) from the environment isn't also
supported too. There's a Java API for JNDI too so folks could look stuff up
in JNDI by hand and do the type conversions - but we've injection for those
values.
Its also much cleaner code and can easily deal generically with type
conversion to long/double/float/date etc.
Compare:
{code}
@Inject Foo(int bar, ...) {
bar = System.getenv("FOO");
if (bar == null) {
bar = "someDefault";
}
// now convert to a String with error handling....
}
{code}
to just:
{code}
@Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
}
{code}
Also by using an annotation it means its very easy to generate
documentation and tooling. (e.g. using APT you can know what all the
environment variables are used by CDI; either to report on demand or to
generate user documentation).
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world
images are static and the main way of injecting configuration is via
environment variables - so that the same image can be reused but configured
at run time with different configuration values. (Changing configuration
files requires either different images to be created or using custom
volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment
variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to
provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of
the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and
whatnot which is cool; I'd be happy if CDI just had a simpler annotation
which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar",
deafultValue="cheese")
> There could be debate on whether env vars or system properties should
win if the same name is used for both; in a dockerized world I'd prefer env
vars to win but folks can always tinker with their run command to make sure
they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
Message: 6
Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST)
From: "James Strachan (JIRA)" <issues(a)jboss.org>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org
Message-ID:
<JIRA.12562481.1423130482000.45773.1423151449139(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
[
https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy...
]
James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM:
-------------------------------------------------------------
@Resource is supported - injecting values from JNDI. I don't see why
injecting values (with a default value) from the environment isn't also
supported too. There's a Java API for JNDI too so folks could look stuff up
in JNDI by hand and do the type conversions - but we've injection for those
values.
Its also much cleaner code and can easily deal generically with type
conversion to long/double/float/date etc.
Compare:
{code}
int bar;
@Inject Foo() {
barText = System.getenv("FOO");
if (barText == null) {
barText = "someDefault";
}
// now convert the String to an int with nice error handling and
reporting....
bar = someConvertCode(barText);
}
{code}
to just:
{code}
@Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
}
{code}
Note that in the second case, folks could use the constructor explicitly
without being bound to environment variables too; much cleaner, more
modular code.
Also by using an annotation it means its very easy to generate
documentation and tooling. (e.g. using APT you can know what all the
environment variables are used by CDI; either to report on demand or to
generate user documentation).
was (Author: jastrachan):
@Resource is supported - injecting values from JNDI. I don't see why
injecting values (with a default value) from the environment isn't also
supported too. There's a Java API for JNDI too so folks could look stuff up
in JNDI by hand and do the type conversions - but we've injection for those
values.
Its also much cleaner code and can easily deal generically with type
conversion to long/double/float/date etc.
Compare:
{code}
@Inject Foo(int bar, ...) {
bar = System.getenv("FOO");
if (bar == null) {
bar = "someDefault";
}
// now convert the String to an int with nice error handling and
reporting....
}
{code}
to just:
{code}
@Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
}
{code}
Also by using an annotation it means its very easy to generate
documentation and tooling. (e.g. using APT you can know what all the
environment variables are used by CDI; either to report on demand or to
generate user documentation).
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world
images are static and the main way of injecting configuration is via
environment variables - so that the same image can be reused but configured
at run time with different configuration values. (Changing configuration
files requires either different images to be created or using custom
volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment
variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to
provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of
the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and
whatnot which is cool; I'd be happy if CDI just had a simpler annotation
which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar",
deafultValue="cheese")
> There could be debate on whether env vars or system properties should
win if the same name is used for both; in a dockerized world I'd prefer env
vars to win but folks can always tinker with their run command to make sure
they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
Message: 7
Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST)
From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org>
Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
annotation like @ConfigProperty from deltapsike
To: cdi-dev(a)lists.jboss.org
Message-ID:
<JIRA.12562481.1423130482000.47108.1423216969246(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
[
https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy...
]
Antoine Sabot-Durand commented on CDI-504:
------------------------------------------
James, I don't get what's the problem with using DeltaSpike config
solution?
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world
images are static and the main way of injecting configuration is via
environment variables - so that the same image can be reused but configured
at run time with different configuration values. (Changing configuration
files requires either different images to be created or using custom
volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment
variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to
provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of
the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and
whatnot which is cool; I'd be happy if CDI just had a simpler annotation
which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar",
deafultValue="cheese")
> There could be debate on whether env vars or system properties should
win if the same name is used for both; in a dockerized world I'd prefer env
vars to win but folks can always tinker with their run command to make sure
they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
------------------------------
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
End of cdi-dev Digest, Vol 51, Issue 9
**************************************