<div dir="ltr"><div class="gmail_default" style="font-size:large">Hi all,</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">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:</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large"><ul><li>Adding a <font face="courier new, monospace">@Configured</font> annotation (basically a qualifier). This can be in addition to<font face="courier new, monospace"> @Inject </font>and would allow to inject "configured" values.<br></li><li>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 <font face="courier new, monospace">@Configured</font> annotation, or an additional <font face="courier new, monospace">@Observable ConfigChangeEvent </font>(similar to the Griffon framework), or both.<br></li><li>Hereby configured values theoretically behave <i>similar </i>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></li><li>The configuration "source" itself could in the extreme simplest way be a <font face="courier new, monospace">Provider<Map<String,String>></font>. 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 <font face="courier new, monospace">ConfigurationSource </font><font face="arial, helvetica, sans-serif">SPI </font>is defined, companies still can hook in the logic and level of configuration abstraction they need.<br></li><li>Of course, since not only <font face="courier new, monospace">Strings </font>can be injected, we need some <i>conversion or adapter logic </i>as basically outlined in my blog. Also here we can add a simple SPI and let the details to the RI.<br></li></ul></div><div class="gmail_default" style="font-size:large">Summarizing a</div><div class="gmail_default" style><ul style><li style><font size="4"><font face="courier new, monospace">@Configured</font> annotation</font></li><li style><font size="4">some kind of change event</font></li><li style><font size="4">a <font face="courier new, monospace">ConfigurationSource </font>extends <font face="courier new, monospace">Provider<MapString,String>></font></font></li><li style><font size="4">a conversion mechanism from String to T.</font></li></ul><div><font size="4">we get a full fledged configuration mechanism that leverages CDI.</font></div><div><font size="4"><br></font></div><div><font size="4">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.</font></div><div><font size="4"><br></font></div><div><font size="4">Best,</font></div><div><font size="4">Anatole</font></div><div><font size="4"><br></font></div></div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large"> </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-09-05 16:08 GMT+02:00 Antonio Goncalves <span dir="ltr"><<a href="mailto:antonio.goncalves@gmail.com" target="_blank">antonio.goncalves@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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"<div><br></div><div>Either we get this idea of "parts" right, or CDI will endup being bloated.</div><div><br></div><div>Antonio</div><div><br></div><div><br></div><div>*David Blevin</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand <span dir="ltr"><<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="word-wrap:break-word">Hi all,<div><br></div><div>You may have followed the rise and fall of the Java Config JSR (<a 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>).</div><div>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.</div><div><br></div><div>I’m mainly thinking of <a 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.</div><span><font color="#888888"><div><br></div><div>Antoine</div><div><br></div><div><br></div></font></span></div><br></div></div>_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/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/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.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Antonio Goncalves <br>Software architect, Java Champion and Pluralsight author<br><br><a href="http://www.antoniogoncalves.org" target="_blank">Web site</a> | <a href="http://twitter.com/agoncal" target="_blank">Twitter</a> | <a href="http://www.linkedin.com/in/agoncal" target="_blank">LinkedIn</a> | <a href="http://pluralsight.com/training/Authors/Details/antonio-goncalves" target="_blank">Pluralsight</a> | <a href="http://www.parisjug.org" target="_blank">Paris JUG</a> | <a href="http://www.devoxx.fr" target="_blank">Devoxx France</a></div>
</font></span></div>
<br>_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/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/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><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><span style="font-family:arial;font-size:small"><b>Anatole Tresch</b></span><div style="font-family:arial;font-size:small">Java Lead Engineer, JSR Spec Lead<br>Glärnischweg 10<br>CH - 8620 Wetzikon</div><div style="font-family:arial;font-size:small"><br></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 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>Mobile +41-76 344 62 79</i></div></div>
</div>