deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
Date Wed, 14 Dec 2011 20:29:36 GMT
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

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