[webbeans-dev] Creating instances of managed beans (including EJBs) in EE6 (was Re: non-contextual managed bean creation)

[Kenneth Saks]

On Aug 13, 2009, at 7:43 AM, Pete Muir wrote:

> Here we need to address a slightly different aspect of managed bean
> lifecycles when CDI is enabled. This has the most impact on EJBs, as
> they are currently the only other direct instantiator of managed  
> beans.
>
> After speaking to Gavin yesterday, and closely reading the latest CDI
> spec, I've noticed that CDI now expects EJB to delegate EJB instance
> creation to CDI, when CDI is enabled in the application. The reason
> for this is to allow EJBs to support constructor injection. IMO there
> are three extremely strong reasons why we need to support this:
>
> 1) Constructor injection is a (very) good thing, because it allows you
> to make a class fully immutable. This will make EJBs a more attractive
> programming model.
> 2) For a developer, it makes adding EJB services to your EJB (or
> removing them) more transparent as constructor injections don't have
> to be altered
> 3) it's required by the 330 and 299 specs
>
> CDI provides an SPI specifically for this purpose with
> InjectionTarget.produce(), so I propose we add a requirement that Web
> Beans integrators have their EJB container call
> injectionTarget.produce() when CDI is enabled in an application to
> create a bean instance.
>
> Clearly, an integrator wouldn't want to hardcode this into their EJB
> container, so a logical way to implement this would be for the EJB
> container to provide a (non-portable) SPI that defines lifecycle
> control for bean instances, along with a default implementation. The
> SPI could look something like this - default implementation also
> described:

I think we'll also need to somehow capture the association to the  
actual EJB component
(e.g. the corresponding org.jboss.webbeans.ejb.spi.EjbDescriptor),  
since that can't
necessarily be derived from the bean class type alone.

>
> * newInstance() - create a new bean instance as required by EJB spec
> * inject() -  perform Java EE style injection
> * postConstruct() - call the @PostConstruct method
> * preDestroy() - call the @PreDestroy method

I agree we need newInstance() and inject(), but I'd rather not delegate
the top-level postConstruct()/preDestroy() operations through the SPI  
since it complicates
the case where there are EJB style (ejb-jar.xml / @Interceptors) and/ 
or CDI style interceptors
associated with the  EJB component.

Let's add a web beans provided interceptor that the EJB container will  
register after any
EJB-style interceptors.  That can handle all interceptors that are  
specified via
CDI-style metadata.



>
> When Web Beans is present, an alternative implementation, which
> instead hooks into the injectionTarget and calls:
>
> * newInstance() - construct an instance, using constructor injection
> via injectionTarget.produce()
> * inject() - inject the instance with CDI-style dependencies and EE-
> style dependencies via injectionTarget().inject()
> * postConstruct() - call @PostConstruct via
> injectionTarget.postConstruct()
> * @PreDestroy - call @PreDestroy via injectionTarget.preDestroy()
>
> As we are discussing in the other email, inject() will then delegate
> back to the container to actually perform the EE style injections
>
> Thoughts?
>
> On 12 Aug 2009, at 23:02, Pete Muir wrote:
>
>> Moving to webbeans-dev. Sorry for the delay in replying...
>>
>> On 11 Aug 2009, at 16:19, Kenneth Saks wrote:
>>
>>> I need to implement the java:global lookup logic defined by the EE 6
>>> Managed Bean spec for the 299-enabled case.    My starting point is
>>> a bean class.  What API/SPI(s) do I call to create a non-contextual
>>> managed bean instance that has been injected(with both 299-style and
>>> EE-style dependencies) and has had  post-construct called?
>>
>> I wrote this generic FAQ http://www.seamframework.org/Documentation/HowDoIDoNoncontextualInjectionForAThirdpartyFramework
>> which describes the process you need to follow.
>>
>> The only difference is that currently inject() doesn't inject any EE
>> style dependencies. This is a bug in the RI. https://jira.jboss.org/jira/browse/WBRI-352
>> _______________________________________________
>> webbeans-dev mailing list
>> webbeans-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev