<div dir="ltr">Actually, as of AS7 JBoss did this with most settings, and as of WildFly 8 anything I could think of could be done via property placeholders (there were a bunch of missing places).<div><br></div><div>I personally like this approach. What I end up doing is something like this:</div><div><br></div><div><session-config></div><div> <cookie-config></div><div> <secure>${http.cookies.secure:false}</secure></div><div>...</div><div><br></div><div><br></div><div>It'll use the config value, if found, and if not found use the default value specified in the placeholder (false). Locally we don't run SSL, but in our external deployments we do, so we just leave it unset locally and give a template properties file for devops to fill in for deployments. Much easier.</div><div><br></div><div>We end up using puppet currently, which seems to like having placeholders over placeholders, so our template properties will look like</div><div><br></div><div>http.cookies.secure=facters['some config prop']</div><div><br></div><div>or something along those lines. Then when it gets deployed the file is generated.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Sep 7, 2014 at 8:46 AM, Mark Struberg <span dir="ltr"><<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;font-size:8pt"><div><span>Yes, the config group also was (obviously) looking at DeltaSpikes config mechanism as well.</span></div><div style="color:rgb(0,0,0);font-size:10.6667px;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;background-color:transparent;font-style:normal"><span>There were others who wanted to go more into the 'filtering' approach as done on WebLogic servers (though not sure who else does that as well).</span></div><div style="color:rgb(0,0,0);font-size:10.6667px;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;background-color:transparent;font-style:normal"><span>You know, having all the XML configs like WEB-INF/web.xml
containing placeholders and the real values only get placed in there at deployment time. I personally find this approach a bit limited from a technical perspective and it already didn't work out for me when using WebLogic (what about changing a configured value after the deployment was done? What about security? Having passwords in web.xml, unit testing, ...).</span></div><div style="color:rgb(0,0,0);font-size:10.6667px;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;background-color:transparent;font-style:normal"><span>There are of course also other approaches which all might have strong sides and would have needed to get discussed.<br></span></div><div style="color:rgb(0,0,0);font-size:10.6667px;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;background-color:transparent;font-style:normal"><br><span></span></div><div style="color:rgb(0,0,0);font-size:10.6667px;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;background-color:transparent;font-style:normal"><span>But utterly the problem seems to have been legal reasons. We even offered to have Anatole/CS lead the EG and do the RI as an ASF project with substantial support and participation from the JBoss, DeltaSpike and TomEE communities.</span></div><div style="color:rgb(0,0,0);font-size:10.6667px;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;background-color:transparent;font-style:normal"><br><span></span></div><div style="color:rgb(0,0,0);font-size:10.6667px;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;background-color:transparent;font-style:normal"><span>Anyway, the time will come when we will resurrect this effort.</span></div><div style="color:rgb(0,0,0);font-size:10.6667px;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;background-color:transparent;font-style:normal"><br><span></span></div><div style="color:rgb(0,0,0);font-size:10.6667px;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;background-color:transparent;font-style:normal"><span>LieGrue,</span></div><div style="color:rgb(0,0,0);font-size:10.6667px;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;background-color:transparent;font-style:normal"><span>strub<br></span></div><div><div class="h5"><div style="color:rgb(0,0,0);font-size:10.6667px;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;background-color:transparent;font-style:normal"><br><span></span></div><div style="color:rgb(0,0,0);font-size:10.6667px;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;background-color:transparent;font-style:normal"><span><br></span></div><div><br><br></div><div style="display:block"> <div style="font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;font-size:8pt"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;font-size:12pt"> <div dir="ltr"> <font face="Arial"> On Sunday, 7 September 2014, 14:29, Werner Keil <<a href="mailto:werner.keil@gmail.com" target="_blank">werner.keil@gmail.com</a>> wrote:<br> </font> </div> <blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;margin-top:5px;padding-left:5px"> <br><br> <div><div><div><div dir="ltr">Yep, it contains a simple but extendable notion of ProjectStage, too;-)<div><div><div dir="ltr"><span style="font-family:arial,sans-serif"></span><div><font face="Arial"><span style="font-family:arial,sans-serif"></span></font><div style="margin:0px;font-size:13px;border-collapse:collapse"><br clear="none"></div></div></div></div><br clear="none"><div><div>On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament <span dir="ltr"><<a rel="nofollow" shape="rect" href="mailto:john.d.ament@gmail.com" target="_blank">john.d.ament@gmail.com</a>></span> wrote:<br clear="none"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Anatole,<div><br clear="none"></div><div>I'm wondering if some of your configuration description falls under what was put together in DeltaSpike?</div><div><br clear="none"></div><div><a rel="nofollow" shape="rect" href="http://deltaspike.apache.org/configuration.html" target="_blank">http://deltaspike.apache.org/configuration.html</a><span><font color="#888888"><br clear="none"></font></span></div><span><font color="#888888"></font></span><div><br clear="none"></div><div>John</div></div><div><div><div><br clear="none"><br clear="none"><div>On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch <span dir="ltr"><<a rel="nofollow" shape="rect" href="mailto:atsticks@gmail.com" target="_blank">atsticks@gmail.com</a>></span> wrote:<br clear="none"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:18px"><span style="font-family:arial,sans-serif">Staging is not a question of xml or not xml (the "format" of config). You can do staged config also using xml, or based on a database or json config service. Staging as well as, more generally speaking, environment dependent config is more like to select/filter the right config that </span><i style="font-family:arial,sans-serif">targets </i><span style="font-family:arial,sans-serif">the current (runtime) environment. This might include stages, but also many other aspects are feasible and common (server, tier, ear, war, tenant ...). Since these aspects are per se very complex, it might be advisable to leave them out of any spec (even a dedicated config JSR would probably not be capable of covering these within the relatively
short EE timeframe)...</span><br clear="none"></div></div><div><div><div><br clear="none"><br clear="none"><div>2014-09-05 23:30 GMT+02:00 Werner Keil <span dir="ltr"><<a rel="nofollow" shape="rect" href="mailto:werner.keil@gmail.com" target="_blank">werner.keil@gmail.com</a>></span>:<br clear="none"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Jens/all,<div><br clear="none"></div><div>A sort of "staging" already was possible using CDI earlier, see examples like this:</div><div><a rel="nofollow" shape="rect" href="http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war" target="_blank">http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-profiles-devel-beta-qa-production-in-one-war</a></div><div><br clear="none"></div><div>DeltaSpike also includes type-safe staging that goes beyond the primitive, hard-coded JSF enum.</div><div><br clear="none"></div><div>If that works without XML, while still allowing flexible configuration for different stages or to add and "inject" additional stages maybe even on a tenant basis (for Cloud scenarios) I could see something like that work without XML. In the Multiconf project we managed to code everything in Python, and similar to Puppet or Chef you can configure and deploy multiple environments with it, Java EE, Spring or Play! several of them are configured this way and it requires no XML (where the container needs such files, the framework generates
them;-)</div><div><br clear="none"></div><div>Werner<div><br clear="none"><div><span>On Fri, Sep 5, 2014 at 10:21 PM, <span dir="ltr"><<a rel="nofollow" shape="rect" href="mailto:cdi-dev-request@lists.jboss.org" target="_blank">cdi-dev-request@lists.jboss.org</a>></span> wrote:<br clear="none"></span><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>Send cdi-dev mailing list submissions to<br clear="none">
<a rel="nofollow" shape="rect" href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br clear="none">
<br clear="none">
To subscribe or unsubscribe via the World Wide Web, visit<br clear="none">
<a rel="nofollow" shape="rect" href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br clear="none">
or, via email, send a message with subject or body 'help' to<br clear="none">
<a rel="nofollow" shape="rect" href="mailto:cdi-dev-request@lists.jboss.org" target="_blank">cdi-dev-request@lists.jboss.org</a><br clear="none">
<br clear="none">
You can reach the person managing the list at<br clear="none">
<a rel="nofollow" shape="rect" href="mailto:cdi-dev-owner@lists.jboss.org" target="_blank">cdi-dev-owner@lists.jboss.org</a><br clear="none">
<br clear="none">
When replying, please edit your Subject line so it is more specific<br clear="none">
than "Re: Contents of cdi-dev digest..."<br clear="none">
<br clear="none">
<br clear="none">
Today's Topics:<br clear="none">
<br clear="none"></span>
1. Re: Tools : Google Drive vs Asciidoc and Github (Anatole Tresch)<br clear="none">
2. Re: With the end of Java Config... (Anatole Tresch)<br clear="none">
3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition<br clear="none">
(Anatole Tresch (JIRA))<br clear="none">
4. Re: With the end of Java Config... (Jens Schumann)<br clear="none">
<br clear="none">
------------------------------<br clear="none">
<br clear="none">
Message: 4<br clear="none">
Date: Fri, 5 Sep 2014 20:20:53 +0000<br clear="none">
From: Jens Schumann <<a rel="nofollow" shape="rect" href="mailto:jens.schumann@openknowledge.de" target="_blank">jens.schumann@openknowledge.de</a>><br clear="none">
Subject: Re: [cdi-dev] With the end of Java Config...<br clear="none">
To: Anatole Tresch <<a rel="nofollow" shape="rect" href="mailto:atsticks@gmail.com" target="_blank">atsticks@gmail.com</a>>, Antonio Goncalves<br clear="none">
<<a rel="nofollow" shape="rect" href="mailto:antonio.goncalves@gmail.com" target="_blank">antonio.goncalves@gmail.com</a>><br clear="none">
Cc: cdi-dev <<a rel="nofollow" shape="rect" href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br clear="none">
Message-ID: <<a rel="nofollow" shape="rect" href="mailto:D02FDD99.396B9%25jens.schumann@openknowledge.de" target="_blank">D02FDD99.396B9%jens.schumann@openknowledge.de</a>><br clear="none">
Content-Type: text/plain; charset="windows-1252"<span><br clear="none">
<br clear="none">
I can confirm that this approach works very well. We are using a similar approach a couple of years now, and I love the simplicity that comes with portable extensions and @Producer methods. See our public version here [1] (works since early CDI 1.0 days) .<br clear="none">
<br clear="none">
Instead of a @Inject + Qualifier we just use the qualifier @Property. We support default values and type conversation for primitives and everything that has a string based constructor. The property source can be anything, from property files (default) to databases or xml files. For examples see tests here [2].<br clear="none">
<br clear="none">
Nevertheless I am not sure if this should be part of an future CDI spec. My concerns include the bloat argument, of course. But the main reason relates to the fact that we have almost everything in the current CDI spec already.<br clear="none">
<br clear="none">
Right now I am quite happy with an custom portable extension that does everything for me. At the time we implemented the extension we realised that the "hard part" was writing an extension that links a qualified "optional injection point" with an @Producer method while supporting code based default values. Luckily I had Arne in my team who did that within a few minutes.<br clear="none">
<br clear="none">
Because of this experience I would propose that we simplify extension development such that "optional injection points" may be linked to @Produces values easily. Additionally we have to solve a few more integration issues (e.g. read-only DB access should be available during CDI startup). Everything else should be provided by portable extensions (e.g. via delta-spike) and documentation/howtos at <a rel="nofollow" shape="rect" href="http://cdi-spec.org/" target="_blank">cdi-spec.org</a>.<br clear="none">
<br clear="none">
Jens<br clear="none">
[1] <a rel="nofollow" shape="rect" href="https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property" target="_blank">https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property</a><br clear="none">
[2] <a rel="nofollow" shape="rect" href="https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property" target="_blank">https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property</a><br clear="none">
<br clear="none"></span>
Von: Anatole Tresch <<a rel="nofollow" shape="rect" href="mailto:atsticks@gmail.com" target="_blank">atsticks@gmail.com</a><mailto:<a rel="nofollow" shape="rect" href="mailto:atsticks@gmail.com" target="_blank">atsticks@gmail.com</a>>><span><br clear="none">
Datum: Friday 5 September 2014 21:22<br clear="none"></span>
An: Antonio Goncalves <<a rel="nofollow" shape="rect" href="mailto:antonio.goncalves@gmail.com" target="_blank">antonio.goncalves@gmail.com</a><mailto:<a rel="nofollow" shape="rect" href="mailto:antonio.goncalves@gmail.com" target="_blank">antonio.goncalves@gmail.com</a>>><br clear="none">
Cc: CDI-Dev <<a rel="nofollow" shape="rect" href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><mailto:<a rel="nofollow" shape="rect" href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>>><span><br clear="none">
Betreff: Re: [cdi-dev] With the end of Java Config...<br clear="none">
<br clear="none">
Hi all,<br clear="none">
<br clear="none">
I would not like to add an XML "bloated" mechanism as part of CDI 2.0. Spontaneously I would propose a more CDI like things like:<br clear="none">
<br clear="none">
<br clear="none"></span>
* Adding a @Configured annotation (basically a qualifier). This can be in addition to @Inject and would allow to inject "configured" values.<br clear="none">
* Since configuration can change we may think of a (CDI) event/reinject mechanism based on config changes. By default, this is switched off and we can discuss how it would be activated, e.g. by an additional flag settable with the @Configured annotation, or an additional @Observable ConfigChangeEvent (similar to the Griffon framework), or both.<br clear="none">
* Hereby configured values theoretically behave similar as all other injection points. They also can be qualified (the aspect of scopes, I did not yet have time to think about). The only difference is, that they are satisified using the configuration "system".<br clear="none">
* The configuration "source" itself could in the extreme simplest way be a Provider<Map<String,String>>. The CDI spec should not care about how this map is provided (XML, DB, overrides, etc). This still can be standardized later. As long as the ConfigurationSource SPI is defined, companies still can hook in the logic and level of configuration abstraction they need.<br clear="none">
* Of course, since not only Strings can be injected, we need some conversion or adapter logic as basically outlined in my blog. Also here we can add a simple SPI and let the details to the RI.<br clear="none">
<br clear="none">
Summarizing a<br clear="none">
<br clear="none">
* @Configured annotation<br clear="none">
* some kind of change event<br clear="none">
* a ConfigurationSource extends Provider<MapString,String>><br clear="none">
* a conversion mechanism from String to T.<span><br clear="none">
<br clear="none">
we get a full fledged configuration mechanism that leverages CDI.<br clear="none">
<br clear="none">
That would be my idea basically. WDYT? I will try to work that out in more details. Basically it should be implementable even with the CDI mechanism already in place with CDI 1.1.<br clear="none">
<br clear="none">
Best,<br clear="none">
Anatole<br clear="none">
<br clear="none">
<br clear="none">
<br clear="none">
<br clear="none">
<br clear="none">
<br clear="none"></span>
2014-09-05 16:08 GMT+02:00 Antonio Goncalves <<a rel="nofollow" shape="rect" href="mailto:antonio.goncalves@gmail.com" target="_blank">antonio.goncalves@gmail.com</a><mailto:<a rel="nofollow" shape="rect" href="mailto:antonio.goncalves@gmail.com" target="_blank">antonio.goncalves@gmail.com</a>>>:<span><br clear="none">
One wise man* once said "EJB was a hype specification, we added too many things to it, it became bloated. The next hype specifications are JAX-RS and CDI, careful with them"<br clear="none">
<br clear="none">
Either we get this idea of "parts" right, or CDI will endup being bloated.<br clear="none">
<br clear="none">
Antonio<br clear="none">
<br clear="none">
<br clear="none">
*David Blevin<br clear="none">
<br clear="none">
<br clear="none"></span><span>
On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand <<a rel="nofollow" shape="rect" href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a><mailto:<a rel="nofollow" shape="rect" href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>>> wrote:<br clear="none">
Hi all,<br clear="none">
<br clear="none">
You may have followed the rise and fall of the Java Config JSR (<a rel="nofollow" shape="rect" href="http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html" target="_blank">http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-dear.html</a>).<br clear="none">
Anatole in CC was leading this initiative and I proposed him to join us and explore if some part of his late-JSR could be done in CDI.<br clear="none">
<br clear="none"></span>
I?m mainly thinking of <a rel="nofollow" shape="rect" href="https://issues.jboss.org/browse/CDI-123" target="_blank">https://issues.jboss.org/browse/CDI-123</a> or related solution. If we achieve to have a majority of specs to integrate with CDI, our configuration solution would therefore become a configuration system for all spec based on CDI 2.0.<span><br clear="none">
<br clear="none">
Antoine<br clear="none">
<br clear="none">
<br clear="none">
<br clear="none">
_______________________________________________<br clear="none">
cdi-dev mailing list<br clear="none">
</span><a rel="nofollow" shape="rect" href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><mailto:<a rel="nofollow" shape="rect" href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><span><br clear="none">
<a rel="nofollow" shape="rect" href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br clear="none">
<br clear="none">
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a rel="nofollow" shape="rect" href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/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 clear="none">
<br clear="none">
<br clear="none">
<br clear="none">
--<br clear="none">
Antonio Goncalves<br clear="none">
Software architect, Java Champion and Pluralsight author<br clear="none">
<br clear="none"></span>
Web site<<a rel="nofollow" shape="rect" href="http://www.antoniogoncalves.org/" target="_blank">http://www.antoniogoncalves.org</a>> | Twitter<<a rel="nofollow" shape="rect" href="http://twitter.com/agoncal" target="_blank">http://twitter.com/agoncal</a>> | LinkedIn<<a rel="nofollow" shape="rect" href="http://www.linkedin.com/in/agoncal" target="_blank">http://www.linkedin.com/in/agoncal</a>> | Pluralsight<<a rel="nofollow" shape="rect" href="http://pluralsight.com/training/Authors/Details/antonio-goncalves" target="_blank">http://pluralsight.com/training/Authors/Details/antonio-goncalves</a>> | Paris JUG<<a rel="nofollow" shape="rect" href="http://www.parisjug.org/" target="_blank">http://www.parisjug.org</a>> | Devoxx France<<a rel="nofollow" shape="rect" href="http://www.devoxx.fr/" target="_blank">http://www.devoxx.fr</a>><br clear="none">
<br clear="none">
_______________________________________________<br clear="none">
cdi-dev mailing list<br clear="none">
<a rel="nofollow" shape="rect" href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><mailto:<a rel="nofollow" shape="rect" href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><span><br clear="none">
<a rel="nofollow" shape="rect" href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br clear="none">
<br clear="none">
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a rel="nofollow" shape="rect" href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/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 clear="none">
<br clear="none">
<br clear="none">
<br clear="none">
--<br clear="none">
Anatole Tresch<br clear="none">
Java Lead Engineer, JSR Spec Lead<br clear="none"></span>
Gl?rnischweg 10<span><br clear="none">
CH - 8620 Wetzikon<br clear="none">
<br clear="none">
Switzerland, Europe Zurich, GMT+1<br clear="none">
Twitter: @atsticks<br clear="none">
Blogs: <a rel="nofollow" shape="rect" href="http://javaremarkables.blogspot.ch/" target="_blank">http://javaremarkables.blogspot.ch/</a><br clear="none">
Google: atsticks<br clear="none">
Mobile <a rel="nofollow" shape="rect">+41-76 344 62 79</a><br clear="none"></span><span>
-------------- next part --------------<br clear="none">
An HTML attachment was scrubbed...<br clear="none"></span>
URL: <a rel="nofollow" shape="rect" href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.html" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/attachment.html</a><br clear="none">
<br clear="none">
------------------------------<span><br clear="none">
<br clear="none">
_______________________________________________<br clear="none">
cdi-dev mailing list<br clear="none">
<a rel="nofollow" shape="rect" href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br clear="none">
<a rel="nofollow" shape="rect" href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br clear="none">
<br clear="none">
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a rel="nofollow" shape="rect" href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/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 clear="none">
<br clear="none"></span>
End of cdi-dev Digest, Vol 46, Issue 20<br clear="none">
***************************************<br clear="none">
</blockquote></div><br clear="none"></div></div></div>
<br clear="none">_______________________________________________<br clear="none">
cdi-dev mailing list<br clear="none">
<a rel="nofollow" shape="rect" href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br clear="none">
<a rel="nofollow" shape="rect" href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br clear="none">
<br clear="none">
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a rel="nofollow" shape="rect" href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/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 clear="none"></blockquote></div><br clear="none"><br clear="all"><div><br clear="none"></div>-- <br clear="none"></div></div><div dir="ltr"><span style="font-family:arial;font-size:small"><b>Anatole Tresch</b></span><div style="font-family:arial;font-size:small"><div><div>Java Lead Engineer, JSR Spec Lead<br clear="none"></div></div>Glärnischweg 10<br clear="none">CH - 8620 Wetzikon</div><span></span><div style="font-family:arial;font-size:small"><br clear="none"></div><div style="font-family:arial;font-size:small"><i>Switzerland, Europe Zurich, GMT+1</i></div><div style="font-family:arial;font-size:small"><i>Twitter: @atsticks</i></div><div><i style="font-family:arial;font-size:small">Blogs: </i><font face="arial"><i><a rel="nofollow" shape="rect" href="http://javaremarkables.blogspot.ch/" target="_blank">http://javaremarkables.blogspot.ch/</a></i></font></div><div style="font-family:arial;font-size:small"><i>Google: atsticks<br clear="none">Mobile <a rel="nofollow" shape="rect">+41-76 344 62 79</a></i></div></div>
</div>
<br clear="none">_______________________________________________<br clear="none">
cdi-dev mailing list<br clear="none">
<a rel="nofollow" shape="rect" href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br clear="none">
<a rel="nofollow" shape="rect" href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br clear="none">
<br clear="none">
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a rel="nofollow" shape="rect" href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/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 clear="none"></blockquote></div><br clear="none"></div>
</div></div></blockquote></div></div><br clear="none"></div></div></div></div><br><div>_______________________________________________<br clear="none">cdi-dev mailing list<br clear="none"><a shape="rect" href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br clear="none"><a shape="rect" href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br clear="none"><br clear="none">Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a shape="rect" href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/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.</div><br><br></div> </blockquote>
</div> </div> </div> </div></div></div></div></blockquote></div><br></div>