[webbeans-dev] Providing EE style injection (was Re: non-contextual managed bean creation)

[Pete Muir]

There are a couple of additional points to make to this. The first  
I'll address here, the second in a followup email.

Ken and I had a discussion about who should be responsible for  
performing EE-style injection on an EE component. Currently, Web Beans  
will perform some EE-style injections, depending on the type of  
object. Obviously, we should clarify this, especially in light of the  
lifecycle changes discussed in the followup email, and below.

The current proposal for performing injection on EE component classes  
inside an EE environment, which I know Ken and Jason are happy with  
(though I wasn't clear if Carlo, Roger and Ales are on board with it)  
is as follows:

* To perform injection on an EE component class, the container calls  
injectionTarget.inject() as outlined in the FAQ
* Web Beans requests the container perform EE style injections through  
the SPI [1]
* Web Beans performs CDI style field injections and calls initializer  
methods "natively"
* inject() completes

[1] This is a new SPI, which we will need to agree on the design for.  
I would propose:

/**
  * InjectionServices is a per BeanDeploymentArchive service which  
provides  additional
  * injection for any object passed to it. It must be provided in an  
EE environment. Other
  * environments may utilize this service to provide additional  
injections on CDI beans.
  */
interface InjectionServices {

    /**
     * inject() will be called by Web Beans whenever it performs  
injection upon an
     * InjectionTarget or Bean.
     *
     * In an EE environment, inject() must perform EE-style injection  
on the instance, as
     * defined by annotations or deployment descriptors
     */
    void inject(Object instance);

}

There are two non-EE cases we must consider (as Web Beans is also  
targeted at non-EE environments, and CDI can provide injections for  
non-EE components).

1) The case where Web Beans is used in a non-EE environment (Java SE,  
Tomcat etc.). Here, we need to make it is easy to integrate with  
services (which the EE environment has built in) such as JPA and EJB.  
For this reason, we need to keep the EjbServices, JpaServices and  
ResourceServices APIs which provide a simple way to perform  
@PersistenceContext, @EJB and @Resource injections outside of EE  
(which has no generic EE-style injection facility).

2) The case where Web Beans is performing injection on a non-EE  
component . Someone (e.g. Seam) might write an extension to perform  
injection on Wicket component classes; these should receive EE-style  
injections. In an EE environment, the InjectionServices.inject() would  
be called, and expected to perform EE-style injection. In other words,  
the InjectionServices must be able to operate on EE components AND  
other types of components.

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