<div dir="ltr"><div>Hi,</div><div><br></div>Interesting research really.<div><br></div><div>If you'd like to have another example case, both Mojarra (JSF) and Soteria (Security) use a lot of dynamic bean building.</div><div><br></div><div>See e.g.</div><div><br></div><div><a href="https://github.com/jsf-spec/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/cdi/FlashProducer.java">https://github.com/jsf-spec/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/cdi/FlashProducer.java</a><br></div><div><br></div><div>and</div><div><br></div><div><a href="https://github.com/javaee-security-spec/soteria/blob/master/impl/src/main/java/org/glassfish/soteria/cdi/CdiExtension.java#L95">https://github.com/javaee-security-spec/soteria/blob/master/impl/src/main/java/org/glassfish/soteria/cdi/CdiExtension.java#L95</a></div><div><br></div><div>We were already eying the CDI 2.0 BeanBuilder API, but for the meantime have been using our own (less general) version.</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 23, 2016 at 12:56 PM, John D. Ament <span dir="ltr"><<a href="mailto:john.d.ament@gmail.com" target="_blank">john.d.ament@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey guys<div><br></div><div>Based on the last f2f I was in, I took an action item to look at how applications can leverage the new builder methods/classes from this PR: <a href="https://github.com/cdi-spec/cdi/pull/287" target="_blank">https://github.com/cdi-spec/cdi/pull/287</a></div><div><br></div><div>To do this, I took some existing OSS CDI extensions and converted parts to use the new APIs instead of the old ones.</div><div><br></div><div>The results were iffy to be honest. Here's some of the key issues I noticed:</div><div><br></div><div>- AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean<?> bean)</div><div>In the latter, it's clearer to a developer which attributes are required vs optional. Builders typically use sensible defaults. Maybe that was the intention here, but I couldn't really get that sense when converting over. It also wasn't clear what to do when done. I suspect I just leave it, but without some kind of closing "build()" or "done()" method, it becomes ambiguous.</div><div><br></div><div>- Annotated*Configurator</div><div>TBH, I have no idea what I was configuring in this one at the first pass. I started with a method. I wanted to replace the method's annotations. It seemed like I could set that up using the configurator, but I ended up having to do setAnnotated at the end anyways, so I'm not sure what the configurator bought me.</div><div><br></div><div>The one nice thing I saw was the simpler to use lambda functions. Being able to stream through things like annotated method made the code much cleaner.</div><div><br></div><div>For the open source code, I'll try to get some gists together that show the changes. Maybe there's something I'm missing, so wouldn't mind a second set of eyes on the changes to see.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>John</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" 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>