<div dir="ltr">I think everything you're describing are proposed pieces of the original config JSR. CDI shouldn't have any business in doing things like allowing the servlet spec to conditionally register a servlet.<div><br></div><div>John<br><br><div class="gmail_quote">On Mon Feb 09 2015 at 8:09:04 AM arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On Mon, Feb 9, 2015 at 10:51 AM, Mark Struberg <<a href="mailto:struberg@yahoo.de" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=struberg@yahoo.de&cc=&bcc=&su=&body=','_blank');return false;">struberg@yahoo.de</a>> wrote:<br>
> Just curious: What is the need for swapping out overlay XMLs?<br>
<br>
There are many usecases, but one of them it having an extra Servlet in<br>
a few stages (say dev and beta) that gives tools special access to the<br>
application, or a dev filter that provides some extra options for<br>
development.<br>
<br>
Yet another case is swapping out the data-source element in say<br>
application.xml with different versions for each stage.<br>
<br>
> When do you do the replacement? At deploy time? At runtime?<br>
<br>
Most deployment descriptors are processed at deploy time, so when<br>
starting up the application. You specify say a -D parameter when<br>
starting up your server that specifies the stage of your server. The<br>
runtime then chooses an overlay (e.g. extra XML fragment) based on the<br>
value of the stage.<br>
<br>
>What about reconfiguration? Does it need a redeploy?<br>
<br>
The simplest case typically needs a redeploy indeed. Taking the<br>
example with the Servlets; the Servlet API only lets you add and<br>
remove Servlets and Filters during startup of the application.<br>
<br>
> etc. I had to live with it in WebLogic in a project. And to me it felt like it was pretty much broken as it did require a redeployment or at least a server reboot to change the configuration. That's simply a no-go.<br>
<br>
It might have been a no-go for your particular use case, but it's not<br>
in general. It's extremely rare that you need to change the stage of a<br>
running server. Frankly, in well over 10 years of designing, coding<br>
and operating Java EE systems of various sizes, I don't think I've<br>
ever encountered this.<br>
<br>
> It also barely make sense in a time where most specs got completely rid of XML configs.<br>
<br>
Wishful thinking if you'd ask me. While we surely go to more defaults<br>
and not *requiring* any upfront XML config if the user is satisfied<br>
with those defaults, Java EE is still firmly rooted in XML config.<br>
Quite a lot of configuration scenarios are contextual and not<br>
naturally expressibly in key/value pairs. I can speak for the JSF EG,<br>
and at least in JSF there is no moving to anything other than XML<br>
config (we have in fact discussed this). I'm not aware of anything in<br>
the Servlet EG either. Things like a Filter definition with their<br>
nested init params or security constraints etc are just not that<br>
naturally expressed as key/value pairs. JSON perhaps, but not<br>
key/value.<br>
<br>
I strongly believe there are two main aspects of configuration that<br>
should not be confused:<br>
<br>
1. Configuring the container<br>
2. Configuring the application<br>
<br>
Where configuring is a matter of:<br>
<br>
1. Overlaying XML fragments (in practice mostly a relatively simply<br>
matter of choosing which fragment to include or not)<br>
2. Providing EL or EL-like placeholders in XML and annotations<br>
3. Providing key/values (and injecting them info the application)<br>
<br>
Both the container itself and the application can theoretically take<br>
advantage of any of these options, but it practice it seems the<br>
container configuration leans more towards 1, while the application<br>
leans more towards 3.<br>
<br>
I felt that the Java EE configuration JSR, now Tamaya, largely<br>
focussed on providing key/values and a means of injecting them into<br>
the application, and didn't think at all about deployment descriptors<br>
and placeholders in them.<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
<br>
<br>
<br>
<br>
><br>
><br>
><br>
>> If DeltaSpike Configuration already covered everything<br>
><br>
>> there would have been no need for Tamaya;-)<br>
><br>
> The main goal is to get a JSR running. If we don't achieve this then there is really not that much benefit in Tamaya. But I am really hopeful that we DO get this done!<br>
><br>
><br>
><br>
> LieGrue,<br>
> strub<br>
><br>
><br>
><br>
> On Friday, 6 February 2015, 13:34, Werner Keil <<a href="mailto:werner.keil@gmail.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=werner.keil@gmail.com&cc=&bcc=&su=&body=','_blank');return false;">werner.keil@gmail.com</a>> wrote:<br>
>><br>
>>If DeltaSpike Configuration already covered everything there would have been no need for Tamaya;-)<br>
>><br>
>><br>
>>On Fri, Feb 6, 2015 at 1:23 PM, arjan tijms <<a href="mailto:arjan.tijms@gmail.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=arjan.tijms@gmail.com&cc=&bcc=&su=&body=','_blank');return false;">arjan.tijms@gmail.com</a>> wrote:<br>
>><br>
>>Hi,<br>
>>><br>
>>>On Fri, Feb 6, 2015 at 11:22 AM, Werner Keil <<a href="mailto:werner.keil@gmail.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=werner.keil@gmail.com&cc=&bcc=&su=&body=','_blank');return false;">werner.keil@gmail.com</a>> wrote:<br>
>>>> but so far JCP officials first and foremost<br>
>>>> Oracle saw either no need or no resources to do this.<br>
>>><br>
>>>I remember some other issues being on the table, like Java SE vs Java<br>
>>>EE and "configuring the runtime" vs "injecting/providing values to the<br>
>>>app".<br>
>>><br>
>>>DeltaSpike Configuration is really great, but it's a value provider.<br>
>>>It doesn't let you swap out or overlay deployment descriptors etc.<br>
>>><br>
>>>Kind regards,<br>
>>>Arjan Tijms<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>>><br>
>>>> Apache Tamaya was a logical result. If that could become a blue-print or<br>
>>>> initial contribution of a future JSR, let's see, maybe for EE 9. It uses<br>
>>>> other Apache projects like DeltaSpike where applicable, but may also define<br>
>>>> such annotations and types of its own, so I suggest you also share your<br>
>>>> ideas on a Tamaya mailing list or JIRA:<br>
>>>> <a href="http://tamaya.incubator.apache.org/index.html" target="_blank">http://tamaya.incubator.<u></u>apache.org/index.html</a><br>
>>>><br>
>>>> On Fri, Feb 6, 2015 at 11:02 AM, <<a href="mailto:cdi-dev-request@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev-request@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev-request@lists.jboss.<u></u>org</a>> wrote:<br>
>>>>><br>
>>>>> Send cdi-dev mailing list submissions to<br>
>>>>> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a><br>
>>>>><br>
>>>>> To subscribe or unsubscribe via the World Wide Web, visit<br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/cdi-dev</a><br>
>>>>> or, via email, send a message with subject or body 'help' to<br>
>>>>> <a href="mailto:cdi-dev-request@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev-request@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev-request@lists.jboss.<u></u>org</a><br>
>>>>><br>
>>>>> You can reach the person managing the list at<br>
>>>>> <a href="mailto:cdi-dev-owner@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev-owner@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev-owner@lists.jboss.org</a><br>
>>>>><br>
>>>>> When replying, please edit your Subject line so it is more specific<br>
>>>>> than "Re: Contents of cdi-dev digest..."<br>
>>>>><br>
>>>>><br>
>>>>> Today's Topics:<br>
>>>>><br>
>>>>> 1. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>>>>> @ConfigProperty from deltapsike (James Strachan (JIRA))<br>
>>>>> 2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>>>>> @ConfigProperty from deltapsike (Martin Kouba (JIRA))<br>
>>>>> 3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>>>>> @ConfigProperty from deltapsike (John Ament (JIRA))<br>
>>>>> 4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>>>>> @ConfigProperty from deltapsike (James Strachan (JIRA))<br>
>>>>> 5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>>>>> @ConfigProperty from deltapsike (James Strachan (JIRA))<br>
>>>>> 6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>>>>> @ConfigProperty from deltapsike (James Strachan (JIRA))<br>
>>>>> 7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like<br>
>>>>> @ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA))<br>
>>>>><br>
>>>>><br>
>>>>> ------------------------------<u></u>------------------------------<u></u>----------<br>
>>>>><br>
>>>>> Message: 1<br>
>>>>> Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST)<br>
>>>>> From: "James Strachan (JIRA)" <<a href="mailto:issues@jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=issues@jboss.org&cc=&bcc=&su=&body=','_blank');return false;">issues@jboss.org</a>><br>
>>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>>>>> annotation like @ConfigProperty from deltapsike<br>
>>>>> To: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a><br>
>>>>> Message-ID:<br>
>>>>> <JIRA.12562481.1423130482000.<u></u>44616.1423130509034@Atlassian.<u></u>JIRA><br>
>>>>> Content-Type: text/plain; charset=UTF-8<br>
>>>>><br>
>>>>> James Strachan created CDI-504:<br>
>>>>> ------------------------------<u></u>----<br>
>>>>><br>
>>>>> Summary: have a standard CDI annotation like @ConfigProperty<br>
>>>>> from deltapsike<br>
>>>>> Key: CDI-504<br>
>>>>> URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/<u></u>browse/CDI-504</a><br>
>>>>> Project: CDI Specification Issues<br>
>>>>> Issue Type: Feature Request<br>
>>>>> Reporter: James Strachan<br>
>>>>><br>
>>>>><br>
>>>>> Docker and containerisation is the new hotness; in the docker world images<br>
>>>>> are static and the main way of injecting configuration is via environment<br>
>>>>> variables - so that the same image can be reused but configured at run time<br>
>>>>> with different configuration values. (Changing configuration files requires<br>
>>>>> either different images to be created or using custom volumes which is less<br>
>>>>> ideal in a containerized world).<br>
>>>>><br>
>>>>> So IMHO CDI should provide a simple, natural way to allow environment<br>
>>>>> variables (or system properties) to be easily injected via CDI.<br>
>>>>><br>
>>>>> Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>>>>> <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/<u></u>documentation/configuration.<u></u>html</a><br>
>>>>><br>
>>>>> you can specify a name, default value and use it on an @Inject to provide<br>
>>>>> a value from env vars, system properties or provide a default.<br>
>>>>><br>
>>>>> Given how core and useful this is - it feels like it should be part of the<br>
>>>>> CDI specification; its one simple annotation.<br>
>>>>><br>
>>>>> Currently deltaspike provides a way to configure different sources and<br>
>>>>> whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>>>>> which was only bound to env vars / system properties.<br>
>>>>><br>
>>>>> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>>>>><br>
>>>>> There could be debate on whether env vars or system properties should win<br>
>>>>> if the same name is used for both; in a dockerized world I'd prefer env vars<br>
>>>>> to win but folks can always tinker with their run command to make sure they<br>
>>>>> pass in env vars as system properties to work around this I guess.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> This message was sent by Atlassian JIRA<br>
>>>>> (v6.3.11#6341)<br>
>>>>><br>
>>>>><br>
>>>>> ------------------------------<br>
>>>>><br>
>>>>> Message: 2<br>
>>>>> Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST)<br>
>>>>> From: "Martin Kouba (JIRA)" <<a href="mailto:issues@jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=issues@jboss.org&cc=&bcc=&su=&body=','_blank');return false;">issues@jboss.org</a>><br>
>>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>>>>> annotation like @ConfigProperty from deltapsike<br>
>>>>> To: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a><br>
>>>>> Message-ID:<br>
>>>>> <JIRA.12562481.1423130482000.<u></u>45712.1423150250888@Atlassian.<u></u>JIRA><br>
>>>>> Content-Type: text/plain; charset=UTF-8<br>
>>>>><br>
>>>>><br>
>>>>> [<br>
>>>>> <a href="https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038005#comment-13038005" target="_blank">https://issues.jboss.org/<u></u>browse/CDI-504?page=com.<u></u>atlassian.jira.plugin.system.<u></u>issuetabpanels:comment-<u></u>tabpanel&focusedCommentId=<u></u>13038005#comment-13038005</a><br>
>>>>> ]<br>
>>>>><br>
>>>>> Martin Kouba commented on CDI-504:<br>
>>>>> ------------------------------<u></u>----<br>
>>>>><br>
>>>>> What's wrong with {{java.lang.System.<u></u>getProperty()}} and<br>
>>>>> {{java.lang.System.getenv()}}? I mean the main advantage of DS Configuration<br>
>>>>> is IMO the resolution mechanism and the ability to extend the set of<br>
>>>>> {{ConfigSource}} s. If you only need system properties and env variables a<br>
>>>>> simple producer method and qualifier (or even a simple util method) would be<br>
>>>>> sufficient. In other words I see no reason to standardize this.<br>
>>>>><br>
>>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike<br>
>>>>> > ------------------------------<u></u>------------------------------<u></u>-------<br>
>>>>> ><br>
>>>>> > Key: CDI-504<br>
>>>>> > URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/<u></u>browse/CDI-504</a><br>
>>>>> > Project: CDI Specification Issues<br>
>>>>> > Issue Type: Feature Request<br>
>>>>> > Reporter: James Strachan<br>
>>>>> ><br>
>>>>> > Docker and containerisation is the new hotness; in the docker world<br>
>>>>> > images are static and the main way of injecting configuration is via<br>
>>>>> > environment variables - so that the same image can be reused but configured<br>
>>>>> > at run time with different configuration values. (Changing configuration<br>
>>>>> > files requires either different images to be created or using custom volumes<br>
>>>>> > which is less ideal in a containerized world).<br>
>>>>> > So IMHO CDI should provide a simple, natural way to allow environment<br>
>>>>> > variables (or system properties) to be easily injected via CDI.<br>
>>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>>>>> > <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/<u></u>documentation/configuration.<u></u>html</a><br>
>>>>> > you can specify a name, default value and use it on an @Inject to<br>
>>>>> > provide a value from env vars, system properties or provide a default.<br>
>>>>> > Given how core and useful this is - it feels like it should be part of<br>
>>>>> > the CDI specification; its one simple annotation.<br>
>>>>> > Currently deltaspike provides a way to configure different sources and<br>
>>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>>>>> > which was only bound to env vars / system properties.<br>
>>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>>>>> > There could be debate on whether env vars or system properties should<br>
>>>>> > win if the same name is used for both; in a dockerized world I'd prefer env<br>
>>>>> > vars to win but folks can always tinker with their run command to make sure<br>
>>>>> > they pass in env vars as system properties to work around this I guess.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> This message was sent by Atlassian JIRA<br>
>>>>> (v6.3.11#6341)<br>
>>>>><br>
>>>>><br>
>>>>> ------------------------------<br>
>>>>><br>
>>>>> Message: 3<br>
>>>>> Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST)<br>
>>>>> From: "John Ament (JIRA)" <<a href="mailto:issues@jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=issues@jboss.org&cc=&bcc=&su=&body=','_blank');return false;">issues@jboss.org</a>><br>
>>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>>>>> annotation like @ConfigProperty from deltapsike<br>
>>>>> To: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a><br>
>>>>> Message-ID:<br>
>>>>> <JIRA.12562481.1423130482000.<u></u>45725.1423150489341@Atlassian.<u></u>JIRA><br>
>>>>> Content-Type: text/plain; charset=UTF-8<br>
>>>>><br>
>>>>><br>
>>>>> [<br>
>>>>> <a href="https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038007#comment-13038007" target="_blank">https://issues.jboss.org/<u></u>browse/CDI-504?page=com.<u></u>atlassian.jira.plugin.system.<u></u>issuetabpanels:comment-<u></u>tabpanel&focusedCommentId=<u></u>13038007#comment-13038007</a><br>
>>>>> ]<br>
>>>>><br>
>>>>> John Ament commented on CDI-504:<br>
>>>>> ------------------------------<u></u>--<br>
>>>>><br>
>>>>> A separate config JSR has been proposed previously to address this. They<br>
>>>>> want to see more options before trying to standardize it.<br>
>>>>><br>
>>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike<br>
>>>>> > ------------------------------<u></u>------------------------------<u></u>-------<br>
>>>>> ><br>
>>>>> > Key: CDI-504<br>
>>>>> > URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/<u></u>browse/CDI-504</a><br>
>>>>> > Project: CDI Specification Issues<br>
>>>>> > Issue Type: Feature Request<br>
>>>>> > Reporter: James Strachan<br>
>>>>> ><br>
>>>>> > Docker and containerisation is the new hotness; in the docker world<br>
>>>>> > images are static and the main way of injecting configuration is via<br>
>>>>> > environment variables - so that the same image can be reused but configured<br>
>>>>> > at run time with different configuration values. (Changing configuration<br>
>>>>> > files requires either different images to be created or using custom volumes<br>
>>>>> > which is less ideal in a containerized world).<br>
>>>>> > So IMHO CDI should provide a simple, natural way to allow environment<br>
>>>>> > variables (or system properties) to be easily injected via CDI.<br>
>>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>>>>> > <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/<u></u>documentation/configuration.<u></u>html</a><br>
>>>>> > you can specify a name, default value and use it on an @Inject to<br>
>>>>> > provide a value from env vars, system properties or provide a default.<br>
>>>>> > Given how core and useful this is - it feels like it should be part of<br>
>>>>> > the CDI specification; its one simple annotation.<br>
>>>>> > Currently deltaspike provides a way to configure different sources and<br>
>>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>>>>> > which was only bound to env vars / system properties.<br>
>>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>>>>> > There could be debate on whether env vars or system properties should<br>
>>>>> > win if the same name is used for both; in a dockerized world I'd prefer env<br>
>>>>> > vars to win but folks can always tinker with their run command to make sure<br>
>>>>> > they pass in env vars as system properties to work around this I guess.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> This message was sent by Atlassian JIRA<br>
>>>>> (v6.3.11#6341)<br>
>>>>><br>
>>>>><br>
>>>>> ------------------------------<br>
>>>>><br>
>>>>> Message: 4<br>
>>>>> Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST)<br>
>>>>> From: "James Strachan (JIRA)" <<a href="mailto:issues@jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=issues@jboss.org&cc=&bcc=&su=&body=','_blank');return false;">issues@jboss.org</a>><br>
>>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>>>>> annotation like @ConfigProperty from deltapsike<br>
>>>>> To: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a><br>
>>>>> Message-ID:<br>
>>>>> <JIRA.12562481.1423130482000.<u></u>45741.1423150789541@Atlassian.<u></u>JIRA><br>
>>>>> Content-Type: text/plain; charset=UTF-8<br>
>>>>><br>
>>>>><br>
>>>>> [<br>
>>>>> <a href="https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012" target="_blank">https://issues.jboss.org/<u></u>browse/CDI-504?page=com.<u></u>atlassian.jira.plugin.system.<u></u>issuetabpanels:comment-<u></u>tabpanel&focusedCommentId=<u></u>13038012#comment-13038012</a><br>
>>>>> ]<br>
>>>>><br>
>>>>> James Strachan commented on CDI-504:<br>
>>>>> ------------------------------<u></u>------<br>
>>>>><br>
>>>>> @Resource is supported - injecting values from JNDI. I don't see why<br>
>>>>> injecting values (with a default value) from the environment isn't also<br>
>>>>> supported too. There's a Java API for JNDI too so folks could look stuff up<br>
>>>>> in JNDI by hand and do the type conversions - but we've injection for those<br>
>>>>> values.<br>
>>>>><br>
>>>>> Its also much cleaner code and can easily deal generically with type<br>
>>>>> conversion to long/double/float/date etc.<br>
>>>>><br>
>>>>> Compare:<br>
>>>>> {code}<br>
>>>>> @Inject Foo(int bar, ...) {<br>
>>>>> bar = System.getenv("FOO");<br>
>>>>> if (bar == null) {<br>
>>>>> bar = "someDefault";<br>
>>>>> }<br>
>>>>> // now convert to a String with error handling....<br>
>>>>> }<br>
>>>>> {code}<br>
>>>>> to just:<br>
>>>>> {code}<br>
>>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {<br>
>>>>> }<br>
>>>>> {code}<br>
>>>>><br>
>>>>> Also by using an annotation it means its very easy to generate<br>
>>>>> documentation and tooling. (e.g. using APT you can know what all the<br>
>>>>> environment variables are used by CDI; either to report on demand or to<br>
>>>>> generate user documentation).<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike<br>
>>>>> > ------------------------------<u></u>------------------------------<u></u>-------<br>
>>>>> ><br>
>>>>> > Key: CDI-504<br>
>>>>> > URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/<u></u>browse/CDI-504</a><br>
>>>>> > Project: CDI Specification Issues<br>
>>>>> > Issue Type: Feature Request<br>
>>>>> > Reporter: James Strachan<br>
>>>>> ><br>
>>>>> > Docker and containerisation is the new hotness; in the docker world<br>
>>>>> > images are static and the main way of injecting configuration is via<br>
>>>>> > environment variables - so that the same image can be reused but configured<br>
>>>>> > at run time with different configuration values. (Changing configuration<br>
>>>>> > files requires either different images to be created or using custom volumes<br>
>>>>> > which is less ideal in a containerized world).<br>
>>>>> > So IMHO CDI should provide a simple, natural way to allow environment<br>
>>>>> > variables (or system properties) to be easily injected via CDI.<br>
>>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>>>>> > <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/<u></u>documentation/configuration.<u></u>html</a><br>
>>>>> > you can specify a name, default value and use it on an @Inject to<br>
>>>>> > provide a value from env vars, system properties or provide a default.<br>
>>>>> > Given how core and useful this is - it feels like it should be part of<br>
>>>>> > the CDI specification; its one simple annotation.<br>
>>>>> > Currently deltaspike provides a way to configure different sources and<br>
>>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>>>>> > which was only bound to env vars / system properties.<br>
>>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>>>>> > There could be debate on whether env vars or system properties should<br>
>>>>> > win if the same name is used for both; in a dockerized world I'd prefer env<br>
>>>>> > vars to win but folks can always tinker with their run command to make sure<br>
>>>>> > they pass in env vars as system properties to work around this I guess.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> This message was sent by Atlassian JIRA<br>
>>>>> (v6.3.11#6341)<br>
>>>>><br>
>>>>><br>
>>>>> ------------------------------<br>
>>>>><br>
>>>>> Message: 5<br>
>>>>> Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST)<br>
>>>>> From: "James Strachan (JIRA)" <<a href="mailto:issues@jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=issues@jboss.org&cc=&bcc=&su=&body=','_blank');return false;">issues@jboss.org</a>><br>
>>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>>>>> annotation like @ConfigProperty from deltapsike<br>
>>>>> To: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a><br>
>>>>> Message-ID:<br>
>>>>> <JIRA.12562481.1423130482000.<u></u>45763.1423151389408@Atlassian.<u></u>JIRA><br>
>>>>> Content-Type: text/plain; charset=UTF-8<br>
>>>>><br>
>>>>><br>
>>>>> [<br>
>>>>> <a href="https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012" target="_blank">https://issues.jboss.org/<u></u>browse/CDI-504?page=com.<u></u>atlassian.jira.plugin.system.<u></u>issuetabpanels:comment-<u></u>tabpanel&focusedCommentId=<u></u>13038012#comment-13038012</a><br>
>>>>> ]<br>
>>>>><br>
>>>>> James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM:<br>
>>>>> ------------------------------<u></u>------------------------------<u></u>-<br>
>>>>><br>
>>>>> @Resource is supported - injecting values from JNDI. I don't see why<br>
>>>>> injecting values (with a default value) from the environment isn't also<br>
>>>>> supported too. There's a Java API for JNDI too so folks could look stuff up<br>
>>>>> in JNDI by hand and do the type conversions - but we've injection for those<br>
>>>>> values.<br>
>>>>><br>
>>>>> Its also much cleaner code and can easily deal generically with type<br>
>>>>> conversion to long/double/float/date etc.<br>
>>>>><br>
>>>>> Compare:<br>
>>>>> {code}<br>
>>>>> @Inject Foo(int bar, ...) {<br>
>>>>> bar = System.getenv("FOO");<br>
>>>>> if (bar == null) {<br>
>>>>> bar = "someDefault";<br>
>>>>> }<br>
>>>>> // now convert the String to an int with nice error handling and<br>
>>>>> reporting....<br>
>>>>> }<br>
>>>>> {code}<br>
>>>>> to just:<br>
>>>>> {code}<br>
>>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {<br>
>>>>> }<br>
>>>>> {code}<br>
>>>>><br>
>>>>> Also by using an annotation it means its very easy to generate<br>
>>>>> documentation and tooling. (e.g. using APT you can know what all the<br>
>>>>> environment variables are used by CDI; either to report on demand or to<br>
>>>>> generate user documentation).<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> was (Author: jastrachan):<br>
>>>>> @Resource is supported - injecting values from JNDI. I don't see why<br>
>>>>> injecting values (with a default value) from the environment isn't also<br>
>>>>> supported too. There's a Java API for JNDI too so folks could look stuff up<br>
>>>>> in JNDI by hand and do the type conversions - but we've injection for those<br>
>>>>> values.<br>
>>>>><br>
>>>>> Its also much cleaner code and can easily deal generically with type<br>
>>>>> conversion to long/double/float/date etc.<br>
>>>>><br>
>>>>> Compare:<br>
>>>>> {code}<br>
>>>>> @Inject Foo(int bar, ...) {<br>
>>>>> bar = System.getenv("FOO");<br>
>>>>> if (bar == null) {<br>
>>>>> bar = "someDefault";<br>
>>>>> }<br>
>>>>> // now convert to a String with error handling....<br>
>>>>> }<br>
>>>>> {code}<br>
>>>>> to just:<br>
>>>>> {code}<br>
>>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {<br>
>>>>> }<br>
>>>>> {code}<br>
>>>>><br>
>>>>> Also by using an annotation it means its very easy to generate<br>
>>>>> documentation and tooling. (e.g. using APT you can know what all the<br>
>>>>> environment variables are used by CDI; either to report on demand or to<br>
>>>>> generate user documentation).<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike<br>
>>>>> > ------------------------------<u></u>------------------------------<u></u>-------<br>
>>>>> ><br>
>>>>> > Key: CDI-504<br>
>>>>> > URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/<u></u>browse/CDI-504</a><br>
>>>>> > Project: CDI Specification Issues<br>
>>>>> > Issue Type: Feature Request<br>
>>>>> > Reporter: James Strachan<br>
>>>>> ><br>
>>>>> > Docker and containerisation is the new hotness; in the docker world<br>
>>>>> > images are static and the main way of injecting configuration is via<br>
>>>>> > environment variables - so that the same image can be reused but configured<br>
>>>>> > at run time with different configuration values. (Changing configuration<br>
>>>>> > files requires either different images to be created or using custom volumes<br>
>>>>> > which is less ideal in a containerized world).<br>
>>>>> > So IMHO CDI should provide a simple, natural way to allow environment<br>
>>>>> > variables (or system properties) to be easily injected via CDI.<br>
>>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>>>>> > <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/<u></u>documentation/configuration.<u></u>html</a><br>
>>>>> > you can specify a name, default value and use it on an @Inject to<br>
>>>>> > provide a value from env vars, system properties or provide a default.<br>
>>>>> > Given how core and useful this is - it feels like it should be part of<br>
>>>>> > the CDI specification; its one simple annotation.<br>
>>>>> > Currently deltaspike provides a way to configure different sources and<br>
>>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>>>>> > which was only bound to env vars / system properties.<br>
>>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>>>>> > There could be debate on whether env vars or system properties should<br>
>>>>> > win if the same name is used for both; in a dockerized world I'd prefer env<br>
>>>>> > vars to win but folks can always tinker with their run command to make sure<br>
>>>>> > they pass in env vars as system properties to work around this I guess.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> This message was sent by Atlassian JIRA<br>
>>>>> (v6.3.11#6341)<br>
>>>>><br>
>>>>><br>
>>>>> ------------------------------<br>
>>>>><br>
>>>>> Message: 6<br>
>>>>> Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST)<br>
>>>>> From: "James Strachan (JIRA)" <<a href="mailto:issues@jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=issues@jboss.org&cc=&bcc=&su=&body=','_blank');return false;">issues@jboss.org</a>><br>
>>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>>>>> annotation like @ConfigProperty from deltapsike<br>
>>>>> To: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a><br>
>>>>> Message-ID:<br>
>>>>> <JIRA.12562481.1423130482000.<u></u>45773.1423151449139@Atlassian.<u></u>JIRA><br>
>>>>> Content-Type: text/plain; charset=UTF-8<br>
>>>>><br>
>>>>><br>
>>>>> [<br>
>>>>> <a href="https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012" target="_blank">https://issues.jboss.org/<u></u>browse/CDI-504?page=com.<u></u>atlassian.jira.plugin.system.<u></u>issuetabpanels:comment-<u></u>tabpanel&focusedCommentId=<u></u>13038012#comment-13038012</a><br>
>>>>> ]<br>
>>>>><br>
>>>>> James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM:<br>
>>>>> ------------------------------<u></u>------------------------------<u></u>-<br>
>>>>><br>
>>>>> @Resource is supported - injecting values from JNDI. I don't see why<br>
>>>>> injecting values (with a default value) from the environment isn't also<br>
>>>>> supported too. There's a Java API for JNDI too so folks could look stuff up<br>
>>>>> in JNDI by hand and do the type conversions - but we've injection for those<br>
>>>>> values.<br>
>>>>><br>
>>>>> Its also much cleaner code and can easily deal generically with type<br>
>>>>> conversion to long/double/float/date etc.<br>
>>>>><br>
>>>>> Compare:<br>
>>>>> {code}<br>
>>>>> int bar;<br>
>>>>> @Inject Foo() {<br>
>>>>> barText = System.getenv("FOO");<br>
>>>>> if (barText == null) {<br>
>>>>> barText = "someDefault";<br>
>>>>> }<br>
>>>>> // now convert the String to an int with nice error handling and<br>
>>>>> reporting....<br>
>>>>> bar = someConvertCode(barText);<br>
>>>>> }<br>
>>>>> {code}<br>
>>>>> to just:<br>
>>>>> {code}<br>
>>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {<br>
>>>>> }<br>
>>>>> {code}<br>
>>>>><br>
>>>>> Note that in the second case, folks could use the constructor explicitly<br>
>>>>> without being bound to environment variables too; much cleaner, more modular<br>
>>>>> code.<br>
>>>>><br>
>>>>> Also by using an annotation it means its very easy to generate<br>
>>>>> documentation and tooling. (e.g. using APT you can know what all the<br>
>>>>> environment variables are used by CDI; either to report on demand or to<br>
>>>>> generate user documentation).<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> was (Author: jastrachan):<br>
>>>>> @Resource is supported - injecting values from JNDI. I don't see why<br>
>>>>> injecting values (with a default value) from the environment isn't also<br>
>>>>> supported too. There's a Java API for JNDI too so folks could look stuff up<br>
>>>>> in JNDI by hand and do the type conversions - but we've injection for those<br>
>>>>> values.<br>
>>>>><br>
>>>>> Its also much cleaner code and can easily deal generically with type<br>
>>>>> conversion to long/double/float/date etc.<br>
>>>>><br>
>>>>> Compare:<br>
>>>>> {code}<br>
>>>>> @Inject Foo(int bar, ...) {<br>
>>>>> bar = System.getenv("FOO");<br>
>>>>> if (bar == null) {<br>
>>>>> bar = "someDefault";<br>
>>>>> }<br>
>>>>> // now convert the String to an int with nice error handling and<br>
>>>>> reporting....<br>
>>>>> }<br>
>>>>> {code}<br>
>>>>> to just:<br>
>>>>> {code}<br>
>>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {<br>
>>>>> }<br>
>>>>> {code}<br>
>>>>><br>
>>>>> Also by using an annotation it means its very easy to generate<br>
>>>>> documentation and tooling. (e.g. using APT you can know what all the<br>
>>>>> environment variables are used by CDI; either to report on demand or to<br>
>>>>> generate user documentation).<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike<br>
>>>>> > ------------------------------<u></u>------------------------------<u></u>-------<br>
>>>>> ><br>
>>>>> > Key: CDI-504<br>
>>>>> > URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/<u></u>browse/CDI-504</a><br>
>>>>> > Project: CDI Specification Issues<br>
>>>>> > Issue Type: Feature Request<br>
>>>>> > Reporter: James Strachan<br>
>>>>> ><br>
>>>>> > Docker and containerisation is the new hotness; in the docker world<br>
>>>>> > images are static and the main way of injecting configuration is via<br>
>>>>> > environment variables - so that the same image can be reused but configured<br>
>>>>> > at run time with different configuration values. (Changing configuration<br>
>>>>> > files requires either different images to be created or using custom volumes<br>
>>>>> > which is less ideal in a containerized world).<br>
>>>>> > So IMHO CDI should provide a simple, natural way to allow environment<br>
>>>>> > variables (or system properties) to be easily injected via CDI.<br>
>>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>>>>> > <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/<u></u>documentation/configuration.<u></u>html</a><br>
>>>>> > you can specify a name, default value and use it on an @Inject to<br>
>>>>> > provide a value from env vars, system properties or provide a default.<br>
>>>>> > Given how core and useful this is - it feels like it should be part of<br>
>>>>> > the CDI specification; its one simple annotation.<br>
>>>>> > Currently deltaspike provides a way to configure different sources and<br>
>>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>>>>> > which was only bound to env vars / system properties.<br>
>>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>>>>> > There could be debate on whether env vars or system properties should<br>
>>>>> > win if the same name is used for both; in a dockerized world I'd prefer env<br>
>>>>> > vars to win but folks can always tinker with their run command to make sure<br>
>>>>> > they pass in env vars as system properties to work around this I guess.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> This message was sent by Atlassian JIRA<br>
>>>>> (v6.3.11#6341)<br>
>>>>><br>
>>>>><br>
>>>>> ------------------------------<br>
>>>>><br>
>>>>> Message: 7<br>
>>>>> Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST)<br>
>>>>> From: "Antoine Sabot-Durand (JIRA)" <<a href="mailto:issues@jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=issues@jboss.org&cc=&bcc=&su=&body=','_blank');return false;">issues@jboss.org</a>><br>
>>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI<br>
>>>>> annotation like @ConfigProperty from deltapsike<br>
>>>>> To: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a><br>
>>>>> Message-ID:<br>
>>>>> <JIRA.12562481.1423130482000.<u></u>47108.1423216969246@Atlassian.<u></u>JIRA><br>
>>>>> Content-Type: text/plain; charset=UTF-8<br>
>>>>><br>
>>>>><br>
>>>>> [<br>
>>>>> <a href="https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038271#comment-13038271" target="_blank">https://issues.jboss.org/<u></u>browse/CDI-504?page=com.<u></u>atlassian.jira.plugin.system.<u></u>issuetabpanels:comment-<u></u>tabpanel&focusedCommentId=<u></u>13038271#comment-13038271</a><br>
>>>>> ]<br>
>>>>><br>
>>>>> Antoine Sabot-Durand commented on CDI-504:<br>
>>>>> ------------------------------<u></u>------------<br>
>>>>><br>
>>>>> James, I don't get what's the problem with using DeltaSpike config<br>
>>>>> solution?<br>
>>>>><br>
>>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike<br>
>>>>> > ------------------------------<u></u>------------------------------<u></u>-------<br>
>>>>> ><br>
>>>>> > Key: CDI-504<br>
>>>>> > URL: <a href="https://issues.jboss.org/browse/CDI-504" target="_blank">https://issues.jboss.org/<u></u>browse/CDI-504</a><br>
>>>>> > Project: CDI Specification Issues<br>
>>>>> > Issue Type: Feature Request<br>
>>>>> > Reporter: James Strachan<br>
>>>>> ><br>
>>>>> > Docker and containerisation is the new hotness; in the docker world<br>
>>>>> > images are static and the main way of injecting configuration is via<br>
>>>>> > environment variables - so that the same image can be reused but configured<br>
>>>>> > at run time with different configuration values. (Changing configuration<br>
>>>>> > files requires either different images to be created or using custom volumes<br>
>>>>> > which is less ideal in a containerized world).<br>
>>>>> > So IMHO CDI should provide a simple, natural way to allow environment<br>
>>>>> > variables (or system properties) to be easily injected via CDI.<br>
>>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely<br>
>>>>> > <a href="http://deltaspike.apache.org/documentation/configuration.html" target="_blank">http://deltaspike.apache.org/<u></u>documentation/configuration.<u></u>html</a><br>
>>>>> > you can specify a name, default value and use it on an @Inject to<br>
>>>>> > provide a value from env vars, system properties or provide a default.<br>
>>>>> > Given how core and useful this is - it feels like it should be part of<br>
>>>>> > the CDI specification; its one simple annotation.<br>
>>>>> > Currently deltaspike provides a way to configure different sources and<br>
>>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation<br>
>>>>> > which was only bound to env vars / system properties.<br>
>>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")<br>
>>>>> > There could be debate on whether env vars or system properties should<br>
>>>>> > win if the same name is used for both; in a dockerized world I'd prefer env<br>
>>>>> > vars to win but folks can always tinker with their run command to make sure<br>
>>>>> > they pass in env vars as system properties to work around this I guess.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> This message was sent by Atlassian JIRA<br>
>>>>> (v6.3.11#6341)<br>
>>>>><br>
>>>>><br>
>>>>> ------------------------------<br>
>>>>><br>
>>>>> ______________________________<u></u>_________________<br>
>>>>> cdi-dev mailing list<br>
>>>>> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/cdi-dev</a><br>
>>>>><br>
>>>>> Note that for all code provided on this list, the provider licenses the<br>
>>>>> code under the Apache License, Version 2<br>
>>>>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/<u></u>licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>>>>> provided on this list, the provider waives all patent and other intellectual<br>
>>>>> property rights inherent in such information.<br>
>>>>><br>
>>>>> End of cdi-dev Digest, Vol 51, Issue 9<br>
>>>>> ******************************<u></u>********<br>
>>>><br>
>>>><br>
>>>><br>
>>>> ______________________________<u></u>_________________<br>
>>>> cdi-dev mailing list<br>
>>>> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/cdi-dev</a><br>
>>>><br>
>>>> Note that for all code provided on this list, the provider licenses the code<br>
>>>> under the Apache License, Version 2<br>
>>>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/<u></u>licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>>>> provided on this list, the provider waives all patent and other intellectual<br>
>>>> property rights inherent in such information.<br>
>>><br>
>><br>
>>____________________________<u></u>___________________<br>
>>cdi-dev mailing list<br>
>><a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a><br>
>><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/cdi-dev</a><br>
>><br>
>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/<u></u>licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
>><br>
>><br>
<br>
______________________________<u></u>_________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/<u></u>licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
</blockquote></div></div></div>