<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 26 Apr 2011, at 00:07, Rick Hightower wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">We need a general purpose way of finding a BeanManager.<div>+1 for me.</div></blockquote><div><br></div><div>I agree, this is something we can make easier for CDI 1.0. In part we need to see what the javax.inject EG comes up with here, as we build on their foundations. <div><br></div><div>FTR this is a (possibly the?) reason CDI moved away from having a "Container" API -- this is supposed to be addressed by JSR-330 part 2, and so was intentionally left out of CDI 1.0 so that we didn't end up with an inconsistent approach. I need to check with the EE spec lead on the status of the 330-part2 work.</div></div><br><blockquote type="cite"><div><br></div><div>This way should include JNDI lookup to a fallback BeanManagerLocator that uses a ServiceLoader</div><div>+1 for me.</div></blockquote><div><br></div><div>Regarding design for this feature, we should keep it as low footprint in terms of specification and API class as possible, as (always) the impl can make a better decision about how to locate the BM than we can. Rick, can you elaborate on why you want all these additonal JNDI lookup, system property lookup, priority lookup stuff? Comments on each in line.</div><br><blockquote type="cite"><div>
<br></div><div>I think the behavior should look like this:</div><div><br></div><div><ul><li>Lookup BeanManager in JNDI</li></ul></div></blockquote><div>We should avoid requiring this. JNDI lookups are expensive (they require synchronization) compared to straight singleton lookups (which at least two CDI impls, Weld and OWB support today).</div><br><blockquote type="cite"><div><ul><li>If not found, try to load BeanManagerLocator from system property.</li></ul></div></blockquote><div>What is the use case for this?</div><br><blockquote type="cite"><div><ul><li>If not found, try to load BeanManagerLocator from ServiceLoader.</li></ul></div></blockquote><blockquote type="cite"><div><ul>
<li>If more than one BeanManagerLocator found, sort by priority or die if there is more than one. (not sure about the sort, I think it should die, but can be convinced otherwise).</li></ul></div></blockquote><div>Why can it not just be that a service loader is used to find the BeanManagerLocator, and that there must not be more than one property name in use (if there is, it's an error).</div><div><br></div><div>I doubt more than one CDI impl (due to scanning) can be running at the same time, and I'm also not sure this is useful.</div><blockquote type="cite"><div><ul><li>Once the BeanManagerLocator is found, use it to return a BeanManager</li></ul></div></blockquote><div><br></div><div><div><br></div></div><br><blockquote type="cite"><div><ul>
</ul></div><div><br></div><div>In addition,</div><div><br></div><div>I think we need a simplified interface for BeanManager. </div><div><br></div><div><a href="https://github.com/CDISource/cdisource/blob/master/beancontainer/api/src/main/java/org/cdisource/beancontainer/BeanContainer.java">https://github.com/CDISource/cdisource/blob/master/beancontainer/api/src/main/java/org/cdisource/beancontainer/BeanContainer.java</a></div>
<div><br></div><div>This could just be a utility class, but it should be included with CDI 1.1. I think the BeanManager interface is too low level.</div><div><br></div><div><br></div><meta charset="utf-8"><div><br>-- <br>
<b>Rick Hightower</b><br>(415) 968-9037 <br><a href="http://www.google.com/profiles/RichardHightower" target="_blank">Profile</a> <br><br>
</div>
_______________________________________________<br>cdi-dev mailing list<br><a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/cdi-dev<br></blockquote></div><br></body></html>