You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Gerhard Petracek <ge...@gmail.com> on 2011/12/14 20:28:59 UTC
[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
Re: Re : [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Posted by Gerhard Petracek <ge...@gmail.com>.
hi @ all,
it looks like we have an agreement. i'm going to create the corresponding
jira issues.
regards,
gerhard
2011/12/19 Mark Struberg <st...@yahoo.de>
> +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 <ge...@gmail.com>
> > To: deltaspike-dev@incubator.apache.org
> > 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 <ge...@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 <st...@yahoo.de>
> >>
> >>> not stupid at all. +1 for making this more easier to use.
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>> > From: Adrian Gonzalez <ad...@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 <ge...@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 <ch...@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 <li...@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
> >>> > <li...@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
> >>> > <st...@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
> >>> > <ge...@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
> >>> >>
> >>> >
> >>>
> >>
> >>
> >
>
Re: Re : [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Posted by Mark Struberg <st...@yahoo.de>.
+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 <ge...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> 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 <ge...@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 <st...@yahoo.de>
>>
>>> not stupid at all. +1 for making this more easier to use.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> ----- Original Message -----
>>> > From: Adrian Gonzalez <ad...@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 <ge...@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 <ch...@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 <li...@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
>>> > <li...@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
>>> > <st...@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
>>> > <ge...@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
>>> >>
>>> >
>>>
>>
>>
>
Re: Re : [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Posted by Gerhard Petracek <ge...@gmail.com>.
+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 <ge...@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 <st...@yahoo.de>
>
>> not stupid at all. +1 for making this more easier to use.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>> > From: Adrian Gonzalez <ad...@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 <ge...@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 <ch...@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 <li...@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
>> > <li...@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
>> > <st...@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
>> > <ge...@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
>> >>
>> >
>>
>
>
Re: Re : [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Posted by Gerhard Petracek <ge...@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 <st...@yahoo.de>
> not stupid at all. +1 for making this more easier to use.
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: Adrian Gonzalez <ad...@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 <ge...@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 <ch...@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 <li...@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
> > <li...@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
> > <st...@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
> > <ge...@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
> >>
> >
>
Re: Re : [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Posted by Mark Struberg <st...@yahoo.de>.
not stupid at all. +1 for making this more easier to use.
LieGrue,
strub
----- Original Message -----
> From: Adrian Gonzalez <ad...@yahoo.fr>
> To: "deltaspike-dev@incubator.apache.org" <de...@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 <ge...@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 <ch...@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 <li...@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
> <li...@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
> <st...@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
> <ge...@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
>>
>
Re : [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Posted by Adrian Gonzalez <ad...@yahoo.fr>.
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 <ge...@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 <ch...@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 <li...@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 <li...@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 <st...@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 <ge...@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
>
Re: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Posted by Jason Porter <li...@gmail.com>.
+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
<ge...@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 <ge...@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 <ch...@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 <li...@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 <li...@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 <st...@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 <ge...@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
Re: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <ge...@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 <ch...@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 <li...@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 <li...@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 <st...@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 <ge...@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
>>
>
>
Re: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Posted by Gerhard Petracek <ge...@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 <ch...@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 <li...@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 <li...@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 <st...@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 <ge...@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
>
Re: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Posted by Christian Kaltepoth <ch...@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 <li...@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 <li...@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 <st...@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 <ge...@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
Re: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Posted by Jason Porter <li...@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 <li...@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 <st...@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 <ge...@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
Re: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Posted by Jason Porter <li...@gmail.com>.
+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 <st...@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 <ge...@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
Re: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Posted by Mark Struberg <st...@yahoo.de>.
+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 <ge...@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
>