+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 <[email protected]> > To: [email protected] > 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 >
