<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-02-16 12:14 GMT+01:00 Antoine Sabot-Durand <span dir="ltr">&lt;<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>&gt;</span>:<br><blockquote class="gmail_quote" 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"><div dir="ltr"><br><br><div class="gmail_quote"><span class=""><div dir="ltr">Le mar. 16 févr. 2016 à 11:25, Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>&gt; a écrit :<br></div><blockquote class="gmail_quote" 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"><div dir="ltr">Hey guys,<div><br></div><div>thinking more to it here few more remarks/requests:</div><div><br></div><div>- as an extension writer think having an explicit build is better than an implicit one in particular when you manage several built instances. The fact it is sometimes implicit sometimes explicit has these drawbacks:</div><div>-- API starts to be huge for a poor gain</div></div></blockquote><div><br></div></span><div>+1<br></div><span class=""><div> </div><blockquote class="gmail_quote" 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"><div dir="ltr"><div>-- you actually don&#39;t know what is done more easily if not inline (which is likely the case for medium/advanced extensions)</div></div></blockquote><div><br></div></span><div>+1, I think we should remove this notion on Configurator I intoduced, the question ius do we keep specific SPI method returning a builder to be build in a DSL way or not <br></div><span class=""><div> </div><blockquote class="gmail_quote" 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"><div dir="ltr"><div>- why having Builders class with static methods where we could use the bean manager as entry point for them. Would be more natural since the BM already build some instance like AT and easier to find in the IDE and look less magic.</div></div></blockquote><div><br></div></span><div>-1 BM is already bloated with a zillion of methods and as discussed somewhere else some builders (mainly ATB) could be useful from outside CDI, especially in SE to prepare config before starting the container.</div><span class=""><div> </div></span></div></div></blockquote><div><br></div><div>Not a fan of BeanManager but it is the single entry point today. That said most of them are for boot work so events are a good alternative to put them.</div><div> </div><blockquote class="gmail_quote" 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"><div dir="ltr"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" 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"><div dir="ltr"><div>-- bonus on this one: would also bind the calls to a CDI context which makes things easier to track and if we speak later of multiple contexts in the same classloader we wouldn&#39;t be broken</div></div></blockquote><div><br></div></span><div>Remember that built meta-data are mainly used during container bootstrap where context are not active... So I&#39;m not sure to get the interest of this idea.</div><span class=""><font color="#888888"><div><br></div></font></span></div></div></blockquote><div><br></div><div>don&#39;t want to use too much space/time on it since it is not yet on our plate but just to answer the idea was:</div><div><br></div><div>// time execution</div><div>CdiContainer c1 = .....provider(WeldProvider.class).start();</div><div>// c1 lifecycle as expected</div><div><br></div><div>CdiContainer c2 = .....provider(OpenWeabBeansProvider.class).start();<br></div><div>// extension in c2 using OWB cause events - or BM in my first mail - are OWB ones and not Weld ones</div><div><br></div><div><br></div><div><br></div><div>There are few builders we can use at runtime to integrate with 3rd party libs - main thing you want is an InjectionTarget - but guess we have most of them already in CDI 1.2 so think the event proposal works and wouldnt constrained too much integrations.</div><div><br></div><div> </div><blockquote class="gmail_quote" 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"><div dir="ltr"><div class="gmail_quote"><span class=""><font color="#888888"><div></div><div>Antoine</div></font></span><div><div class="h5"><div> </div><blockquote class="gmail_quote" 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"><div dir="ltr"><div><br></div><div><br></div><div>wdyt?</div><div><br></div></div><div class="gmail_extra"></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> |  <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br></div><div class="gmail_extra"><div class="gmail_quote">2016-02-05 16:01 GMT+01:00 Romain Manni-Bucau <span dir="ltr">&lt;<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" 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"><div dir="ltr">Why not making all Annotated* mutable during boot lifecycle?<div><br></div><div>Would allow to get rid of the annotated root in the modification code, for instance we could convert:</div><div><br></div><div>    <span style="color:rgb(44,45,48);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;line-height:22px;background-color:rgb(249,249,249)">type.getMethods().stream().filter(m -&gt; m.isAnnotationPresent(Foo.class)).forEach(m -&gt;event.setAnnotatedType().addToMethod(m, MyInterceptor.BINDING));</span></div><div><span style="color:rgb(44,45,48);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;line-height:22px;background-color:rgb(249,249,249)"><br></span></div>to<div><span style="color:rgb(44,45,48);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;line-height:22px;background-color:rgb(249,249,249)"><br></span></div><div><span style="color:rgb(44,45,48);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;line-height:22px;background-color:rgb(249,249,249)">    </span><span style="color:rgb(44,45,48);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;line-height:22px;background-color:rgb(249,249,249)">type.getMethods().stream().filter(m -&gt; m.isAnnotationPresent(Foo.class)).forEach(m -&gt; m.mutate().add(MyInterceptor.BINDING));</span></div><div><span style="color:rgb(44,45,48);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;line-height:22px;background-color:rgb(249,249,249)"><br></span></div>or if we don&#39;t want to add mutate in the existing types we could use configurator as root for type type and recreate a Configurator graph matching annotated graph.<div><br></div><div>Advatage is first code i a bit awkward in the sense you can call setAnnotatedType() multiple type (what would happen? only last modification will be saved? or you have to keep a reference to the configurator once called which breaks the fluent API provded by streams IMO.</div><div><br></div><div>wdyt?</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> |  <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote"><div><div>2016-02-05 15:24 GMT+01:00 Antoine Sabot-Durand <span dir="ltr">&lt;<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>&gt;</span>:<br></div></div><blockquote class="gmail_quote" 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"><div><div><div dir="ltr"><div>Hi all,</div><div><br></div><div>Following discussion during last meeting, I rewrote most of my PR for builders.</div><div><br></div><div>We now have 2 clean and distinct ways of using them</div><div><br></div><div>1) in DSL style (with a Configurator interface without build() method)</div><div><br></div><div>public void processAT(@Observes ProcessAnnotatedType&lt;?&gt; pat) {</div><div>  pat.setAnnotatedType().read(pat.getAnnotatedType()).addToType(new AnnotationLiteral&lt;MyInterceptor&gt;() {};);</div><div>}</div><div><br></div><div><br></div><div>2) In classical reusable builder mode (builders extends configurator and only add build() method)</div><div><br></div><div><div>public void processAT(@Observes ProcessAnnotatedType&lt;?&gt; pat) {</div><div> AnnotatedTypeBuilder atb = Builders.annotatedTypeBuilder();</div><div> atb.read(pat.getAnnotatedType()).addToType(new  AnnotationLiteral&lt;MyInterceptor&gt;() {};);</div><div>  pat.setAnnotatedType(atb.build());</div><div>}</div></div><div><br></div><div><br></div><div>As Configurators don&#39;t have build() method there&#39;s no risk that users mix them with standard builders.</div><div>For clarity sake, builders are no more available in lifecycle event but in Builders class for consistency.</div><div><br></div><div>I&#39;m quite happy with the result, but I&#39;m sure you&#39;ll have comment ;). So thanks for your feedback</div><div><br></div><div><a href="https://github.com/cdi-spec/cdi/pull/270" target="_blank">https://github.com/cdi-spec/cdi/pull/270</a><span><font color="#888888"><br></font></span></div><span><font color="#888888"><div><br></div><div>Antoine</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" rel="noreferrer" 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" rel="noreferrer" 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></div>
</blockquote></div><br></div></blockquote></div></div></div></div>
</blockquote></div><br></div></div>