[cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike

[James Strachan (JIRA)]

    [ 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)