[cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like
Werner Keil
werner.keil at gmail.com
Fri Feb 6 05:22:35 EST 2015
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 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
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150206/1ea297cc/attachment-0001.html
More information about the cdi-dev
mailing list