deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: Re : [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Date Mon, 19 Dec 2011 13:03:03 GMT
+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 <gerhard.petracek@gmail.com>

> 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 <struberg@yahoo.de>
>
>> not stupid at all. +1 for making this more easier to use.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>> > From: Adrian Gonzalez <adr_gonzalez@yahoo.fr>
>> > To: "deltaspike-dev@incubator.apache.org" <
>> deltaspike-dev@incubator.apache.org>
>> > 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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message