[cdi-dev] Summarize finding a BeanManager (for Java SE, integration with older Java EE and unit testing)

[Rick Hightower]

Inline...

On Tue, Apr 26, 2011 at 12:38 AM, Peter Muir <pmuir at redhat.com> wrote:

>
> On 26 Apr 2011, at 00:07, Rick Hightower wrote:
>
> We need a general purpose way of finding a BeanManager.
> +1 for me.
>
>
> 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.
>
> 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.
>

Ok.


>
>
> This way should include JNDI lookup to a fallback BeanManagerLocator that
> uses a ServiceLoader
> +1 for me.
>
>
> 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.
>
>
> I think the behavior should look like this:
>
>
>    - Lookup BeanManager in JNDI
>
> 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).
>

Ok. But don't singletons wreak havoc with classloaders. What if CDI was
being used as library in a container that did not support CDI (jetty,
tomcat). Wouldn't we want to avoid singletons?

I am ok with dropping JNDI lookup. The CDI container should be in a well
known locations stored in the ServletContext, i.e., application scope. There
should be no classical singleton. There should be nothing that would prevent
a web application restart. We should not assume that CDI will only be used
by Java EE 6. It should be OSGI, web application, re-loadable friendly.

I mentioned JNDI because currently the BeanManager is stored in JNDI.



>
>
>    - If not found, try to load BeanManagerLocator from system property.
>
> What is the use case for this?
>

Flexibility. Let CDI be used in places we have not thought of.


>
>
>    - If not found, try to load BeanManagerLocator from ServiceLoader.
>
>
>    - 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).
>
> 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).
>
> 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.
>

I agree. There should be only one. If there is more than one, it is an
error. I was trying to include the logic that was in Solder. The stuff I
have done, throws as exception if more than one is found.


>
>    - Once the BeanManagerLocator is found, use it to return a BeanManager
>
>
>
>
>
>
>
> In addition,
>
> I think we need a simplified interface for BeanManager.
>
>
> https://github.com/CDISource/cdisource/blob/master/beancontainer/api/src/main/java/org/cdisource/beancontainer/BeanContainer.java
>
> 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.
>
>
>
> --
> *Rick Hightower*
> (415) 968-9037
> Profile <http://www.google.com/profiles/RichardHightower>
>
>  _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>


-- 
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20110426/02dcdd2e/attachment.html