Re: [jboss-dev] Common injection facilities in AS6

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. > I sincerely hope I don't have to escalate this problem to higher levels. > I would much rather have this be a bottom-up lead effort instead of a > top-down enforced directive. > So do I. I think the lead on this needs to come from Jason and team - I would love to be able to register a CDI injector for JBoss AS that would call back to Weld allowing field, method, and constructor injection to occur for all Java EE components rather than the mismatched crap we've had to do. If this matches the CDI InjectionTarget API (seems sensible, reduce API divergence), even better. _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development