not stupid at all. +1 for making this more easier to use. LieGrue, strub
----- Original Message ----- > From: Adrian Gonzalez <[email protected]> > To: "[email protected]" > <[email protected]> > Cc: > Sent: Sunday, December 18, 2011 10:30 PM > Subject: Re : [DISCUSS] [DELTASPIKE-3] BeanManagerProvider > > Hello, > > What's the interest in keeping ByXXX suffix in util methods ? > Aren't method parameters sufficiently symetric and self-explanatory ? > > ie : > public <T> T getContextualReferenceByClass(Class<T> type, boolean > optionalBeanAllowed, Annotation... qualifiers) > would be : > public <T> T getContextualReference(Class<T> type, boolean > optionalBeanAllowed, Annotation... qualifiers) > > Sorry if it's a stupid question though > > ________________________________ > De : Gerhard Petracek <[email protected]> > À : [email protected] > Envoyé le : Vendredi 16 Décembre 2011 0h07 > Objet : Re: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider > > 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 <[email protected]> > >> +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 <[email protected]> >> > >> > 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 > <[email protected]> >> 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 > <[email protected]> >> 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 > <[email protected]> >> > >> > To: [email protected] >> > >> > 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 >> >
