<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 12px; font-family: Arial, sans-serif;">
<div>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)
. </div>
<div><br>
</div>
<div>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].</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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 cdi-spec.org.</div>
<div><br>
</div>
<div>Jens</div>
<div>[1] https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property</div>
<div>[2] https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">Von: </span>Anatole Tresch <<a href="mailto:atsticks@gmail.com">atsticks@gmail.com</a>><br>
<span style="font-weight:bold">Datum: </span>Friday 5 September 2014 21:22<br>
<span style="font-weight:bold">An: </span>Antonio Goncalves <<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>><br>
<span style="font-weight:bold">Cc: </span>CDI-Dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
<span style="font-weight:bold">Betreff: </span>Re: [cdi-dev] With the end of Java Config...<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<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>
</div>
</div>
</blockquote>
</span>
</body>
</html>