[webbeans-dev] EJB lifecycle
Pete Muir
pmuir at redhat.com
Thu Dec 18 18:48:49 EST 2008
Ok, but in 3.3 it says
> Note that multiple enterprise Web Beans may share the same
> implementation class. This occurs when Web Beans are
> defined using XML. Only one Web Bean per implementation class may be
> defined using annotations.
here we have multiple WBs per EJB bean class, so my method below would
fail, no?
On 18 Dec 2008, at 23:42, Gavin King wrote:
> Currently the spec says that there can be only one most specialized
> web bean for a particular ejb bean.
>
> Yep, I thought of that :-)
>
> On Fri, Dec 19, 2008 at 10:33 AM, Pete Muir <pmuir at redhat.com> wrote:
>> Section 6.9 says that we should intercept the @PostConstruct of an
>> EJB to do
>> injection, initialization, interceptor stack binding etc. And this
>> works
>> well :-)
>>
>> So, what I've done is:
>>
>> @PostConstruct
>> public void postConstruct(InvocationContext invocationContext)
>> {
>> Class<?> beanClass = invocationContext.getTarget().getClass();
>> Bean<?> bean =
>> CurrentManager.rootManager().getBeanMap().get(beanClass);
>> if (bean instanceof EnterpriseBean)
>> {
>> EnterpriseBean<Object> enterpriseBean =
>> (EnterpriseBean<Object>)
>> bean;
>> enterpriseBean.postConstruct(invocationContext.getTarget());
>> }
>>
>> To get the relevant Bean, and then run the post construct tasks. I
>> can see
>> two flaws here. First, accessing the manager through current
>> manager, second
>> that there could be multiple Enterprise Beans registered for a
>> particular
>> bean class. In Seam there is some ThreadLocal used to hold the
>> currently
>> invoking bean. Does this seem like the best approach, or am I
>> missing the
>> obvious?
>> _______________________________________________
>> webbeans-dev mailing list
>> webbeans-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>
>
>
>
> --
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
More information about the weld-dev
mailing list