deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Date Thu, 15 Dec 2011 23:18:28 GMT
+1 I'm not a stickler on the names. We have similar utility methods in
Solder. I don't really care where the code comes from either.

On Thu, Dec 15, 2011 at 16:12, Gerhard Petracek
<gerhard.petracek@gmail.com>wrote:

> short additions:
>
> maybe '*byType' is better than '*byClass'. we just called it '*byClass' in
> CodiUtils because we have other methods which have Type as one of its
> parameters.
>
> and we could move the util methods to CdiUtils and there we use
> the BeanManagerProvider (-> we can keep the name BeanManagerProvider)
>
> regards,
> gerhard
>
>
>
> 2011/12/16 Gerhard Petracek <gerhard.petracek@gmail.com>
>
> > 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
> >>
> >
> >
>



-- 
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message