+1 for BeanManagerProvider with generic lookup +1 for CdiUtils and ClassUtils. Although we should review that stuff, because we need to make it explicite which version takes the TCCL and which the class.getClassLoader()
LieGrue, strub ----- Original Message ----- > From: Gerhard Petracek <[email protected]> > To: [email protected] > Cc: > Sent: Monday, December 19, 2011 2:03 PM > Subject: Re: Re : [DISCUSS] [DELTASPIKE-3] BeanManagerProvider > > +1 for BeanManagerProvider > +1 for moving the util methods to CdiUtils (together with methods in Beans > of seam-solder) > +0 for the suggested simple names instead of explicit names > +1 for the method signatures > > regards, > gerhard > > > > 2011/12/18 Gerhard Petracek <[email protected]> > >> hi adrian, >> >> >in general<: >> imo everything should be discussed and every question/opinion is very >> welcome! >> >> @your question: >> it's just easier to add further variations later on and you see >> immediately what you can use. >> (sometimes frameworks add e.g. '2' to get a new method name, if > there's an >> issue with the signature. if i've the choice between explicit names vs. >> "versioned" names, i prefer explicit names. that was the only > reason for >> it.) >> >> i'm also fine with #getContextualReference (that's what we have in > the api >> of myfaces codi right now) -> +0 for both >> >> regards, >> gerhard >> >> >> >> 2011/12/18 Mark Struberg <[email protected]> >> >>> 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 >>> >> >>> > >>> >> >> >
