at [1] i summarized what we have agreed on so far. -> let's continue with the util methods.
suggestions for the util methods: public <T> T getContextualReferenceByClass(Class<T> type, boolean optionalBeanAllowed, Annotation... qualifiers) public <T> T getContextualReferenceByName(String name, boolean optionalBeanAllowed, Class<T> targetType) public <T> T getContextualReferenceByBean(Bean<T> bean, boolean optionalBeanAllowed, Class<T> targetType) and maybe something like public <T> List<T> getContextualReferencesByClass(Class<T> type, boolean optionalBeanAllowed, Annotation... qualifiers) in codi we added the util methods later on. with those util methods it's more than just a BeanManagerProvider -> maybe we find a better name. furthermore we have a static method called isActive which allows to check if the bm and therefore the environment is up and running (we delegate to it in CodiUtils#isCdiInitialized which we are using as a part of our lazy init logic which is required in some cases due to the "early conifg" approach of mojarra). regards, gerhard [1] http://goo.gl/7n2wj 2011/12/15 Christian Kaltepoth <christ...@kaltepoth.de> > +1 (non-binding) > > I really like the proposed solution and I think it's cleaner than the > Solder approach. > > What about obtaining the BeanManager from the ServletContext (which is > specified in CDI 1.1) as an alternative to the JNDI lookup? Do we need > this? It could be interesting for environments that don't support JNDI > (like GAE for example). Solder does this but it requires the > ServletContext to be stored in a ThreadLocal for each request which > isn't very nice. > > I don't think an abstract base class like Solder's BeanManagerAware is > required any more. Obtaining the BM with the proposed API is so simple > that such a base class doesn't make sense. > > Christian > > > 2011/12/14 Jason Porter <lightguard...@gmail.com> > > > > Here we go, right thread this time. The abstract class in Solder is > > > https://github.com/seam/solder/blob/develop/api/src/main/java/org/jboss/solder/beanManager/BeanManagerAware.java > . > > You'll have to follow the code around to see what it exactly does. > > > > On Wed, Dec 14, 2011 at 12:50, Jason Porter <lightguard...@gmail.com> > wrote: > > > > > +1 > > > > > > I think that's a better solution than what we have in Solder. Ours > looks > > > up the BM first in JNDI and then the servlet context if it's not found > (for > > > use in basic servlet containers). Not sure if that's a better approach > than > > > storing it, I do kind of like that approach though. It doesn't sound > like > > > it would be culprit to any memory leaks now that I think about it a bit > > > more. That was my one issue at first. > > > > > > The way we do it in Solder is to have an abstract class so you'd have > to > > > extend that class to get the BM. I'm wondering if you've found cases > where > > > using the observer is too late or you need it the BM at creation time > of > > > the bean. > > > > > > > > > On Wed, Dec 14, 2011 at 12:36, Mark Struberg <strub...@yahoo.de> > wrote: > > > > > >> +1 > > >> btw, it's worth mentioning that the resolution mechanism will first > look > > >> up the BeanManager in JNDI. And only if it isn't available there, it > will > > >> use the one from the system event. > > >> Also we store the BeanManager in a Map<ClassLoader, BeanManager> to be > > >> able to handle EAR situations. > > >> > > >> LieGrue, > > >> strub > > >> > > >> > > >> > > >> ----- Original Message ----- > > >> > From: Gerhard Petracek <gerhard.petra...@gmail.com> > > >> > To: deltaspike-dev@incubator.apache.org > > >> > Cc: > > >> > Sent: Wednesday, December 14, 2011 8:28 PM > > >> > Subject: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider > > >> > > > >> > hi @ all, > > >> > > > >> > fyi: please check [1] before you answer. > > >> > > > >> > [2] provides a short introduction as well as the basic usage. > > >> > > > >> > the basic concept: > > >> > an observer for AfterBeanDiscovery stores the bean-manager for the > > >> current > > >> > application (stored by classloader). > > >> > (see BeanManagerProvider#setBeanManager) > > >> > > > >> > the api: > > >> > BeanManagerProvider.getInstance().getBeanManager() > > >> > > > >> > later on we added some util methods to the api e.g. > > >> #getContextualReference. > > >> > > > >> > the suggestion is to keep the basic concept, usage and api and to > > >> re-visit > > >> > the util methods (e.g. CodiUtils provides some nice internal util > > >> methods > > >> > -> we could promote some of them). > > >> > > > >> > please send > > >> > +1, +0 or -1 because... > > >> > for the basic idea as well as the basic concept which is based on > > >> > the AfterBeanDiscovery event. > > >> > if there are >basic< objections, please also add them to [3] > > >> > > > >> > regards, > > >> > gerhard > > >> > > > >> > [1] http://markmail.org/message/7yefspfuvtz4jvmp > > >> > [2] > > >> > > > >> > https://cwiki.apache.org/confluence/display/EXTCDI/Core+Usage#CoreUsage-BeanManagerProvider > > >> > [3] > > >> > > > >> > https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking > > >> > > > >> > > > > > > > > > > > > -- > > > Jason Porter > > > http://lightguard-jp.blogspot.com > > > http://twitter.com/lightguardjp > > > > > > Software Engineer > > > Open Source Advocate > > > Author of Seam Catch - Next Generation Java Exception Handling > > > > > > PGP key id: 926CCFF5 > > > PGP key available at: keyserver.net, pgp.mit.edu > > > > > > > > > > > -- > > Jason Porter > > http://lightguard-jp.blogspot.com > > http://twitter.com/lightguardjp > > > > Software Engineer > > Open Source Advocate > > Author of Seam Catch - Next Generation Java Exception Handling > > > > PGP key id: 926CCFF5 > > PGP key available at: keyserver.net, pgp.mit.edu > > > > > -- > Christian Kaltepoth > Blog: http://chkal.blogspot.com/ > Twitter: http://twitter.com/chkal >
