On 13 Jun 2010, at 15:07, Pete Muir wrote:
On 13 Jun 2010, at 14:47, Bill Burke wrote:
> I've run smack into a serious problem in AS6.
>
> JAX-RS has injection annotations and I need to:
>
> 1) Inject into a JAX-RS managed POJO
> 2) Inject into an EJB instance
> 3) Inject into CDI bean instance
> 4) Inject into a Managed Bean instance
> 5) I'd also like to support Java EE annotation injection (like @EJB and
> @Resource) into a JAX-RS managed POJO
>
> While the VDF does allow me to find out if which of these components are
> deployed within a WAR so that I easily find out which classes have
> JAX-RS annotations, I have to have different integration with each layer
> for injections.
>
> I am not alone. EJB has EJB specific injection annotations. Java EE
> has common injection annotations, JAX-WS has annotations as well.
> Servlet? There's also a multitude of component layers that need to
> support these annotations: Managed Beans, EJB instances, servlets,
> filters, listeners, JMX Beans, JAX-WS pojos, more?
>
> It would be cool if we had some common facility in which I could do:
>
> Object obj = InjectionFacility.createAndInject(Class<?> someClass)
> InjectionFacility.inject(someArbitraryInstance)
> InjectionFacility.registerInjector(someJAXRSAnnnotationInjector)
>
>
> CDI manages a lot (all?) of this.
Yes, all of this can be done with the InjectionTarget API.
> Unfortunately, I've been told that I
> cannot leverage CDI unless it has been enabled for the deployment.
> Also, I've been told that CDI needs to do a lot of scanning and metadata
> building and it would be counter-productive to do this for each
> deployment. So....
You are failing to differentiate between CDI (a Java EE spec) and Weld (our
implementation of CDI). As I outlined to you on the resteasy mailing list, the reason
*CDI* is not enabled for every *Java EE* deployment is because of concerns (e.g. from
Roberto Chinnici) about overhead. In Weld 1.1 (which we are aiming to release for JBoss AS
6), we will intend to reuse all the scanning/metadata facility of JBoss AS which largely
mitigates this concern IMO.
> 1) Can we find a way to use CDI as our injection facility? Maybe
> turning off CDI scanning, but enabling its plugin and callback APIs and
> SPIs?
Probably this is possible. It would need thought into the expected behavior, but I see no
reason not to do this. In this case, I'm not even that concerned about the scanning
overhead, it is trivial to just not enable scanning in this case.
> or
>
> 2) Can we develop a common facility that all component layers can use
> *INCLUDING* CDI so we don't have to re-invent injection for each and
> every framework?
At first glance, this seems to be the best approach. A modern injection framework for
JBoss AS that can call back to the various frameworks (e.g. Weld, JBoss EJB, MC) to
perform the necessary injections on instances. I know we have some old stuff around this,
which is tightly coupled to EJB etc. We did look at this, but no-one seemed to be able to
understand it.
BTW, today you can, today, make Weld delegate all injection (both CDI style and all other
styles) to the container if you should so want. This is the style that the GlassFish guys
use. It is somewhat circular, as Weld is then asked to perform the CDI style injection via
the InjectionTarget interface ;-)