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