deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Gonzalez <adr_gonza...@yahoo.fr>
Subject Re : [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Date Sun, 18 Dec 2011 21:30:06 GMT
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 <gerhard.petracek@gmail.com>
À : deltaspike-dev@incubator.apache.org 
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 <christian@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.jp@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.jp@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 <struberg@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.petracek@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
>

Mime
View raw message