eclipse-ee4j
Support for parameter injection in CDI
Original issue MVC_SPEC-4 created by Santiago Pericas-Geertsen:
Data binding in MVC will likely take advantage of injection in general, and parameter in injection in particular. Will CDI.next be able to handle the kind of parameter injection that MVC needs?
Comment by Santiago Pericas-Geertsen:
Layering on top of JAX-RS, this becomes more of a JAX-RS issue than an MVC one. However, since MVC is focused exclusively on CDI (unlike JAX-RS), we should look for opportunities to improve parameter injection.
Comment by Santiago Pericas-Geertsen:
Under discussion with CDI spec lead.
Comment by antoinesd:
You'll find my parameter injection POC here: https://github.com/antoinesd/CDI-Sandbox/tree/CDI-1.2/param-inject
Comment by Jozef Hartinger:
Who is calling the methods whose parameters should be injected? If it is the MVC implementation code calling them then there is no need for any further CDI support for this. The caller (MVC impl) can use the existing CDI SPI to obtain values for the parameters and call the method with these values.
Comment by Santiago Pericas-Geertsen:
It's actually done through JAX-RS. But that's beyond the point, there is no question that this can be done "manually". The point is that it shouldn't be done in multiple places (APIs) and possibly in incompatible ways; it should really be factored out and placed where it belongs which is CDI. As an example, JAX-RS supports its own parameter injection mechanism and has never been able to fully align with CDI, among other reasons, due to this missing feature.
Comment by Jozef Hartinger:
I see. So there is nothing actually preventing this right now. The painful point is that it requires several API calls and your request is to add an abstraction to CDI to cover those several steps in a single API call. Is that correct?
Comment by Manfred Riem:
Jozef, that is indeed correct. Is it possible to get that in the BeanManager API?
Comment by rmannibucau:
Like Antoine showed it is doable - even with CDI 1.0 - with a small glue code. Now for JAX-RS it is pretty clear to me it is not the way to go otherwise you would loose - or get in a not deterministic way - the JAX-RS bindings (@Context, @XParam) which are not CDI instances - and will not be cause primitives for instance are not supported by CDI.