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

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