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

Kenneth Saks Kenneth.Saks at Sun.COM
Thu Aug 13 10:24:26 EDT 2009


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

> 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);
>
> }

+1

>
> 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
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev




More information about the weld-dev mailing list