Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for parameter injection in CDI #30

Open
chkal opened this issue Jul 19, 2020 · 8 comments
Open

Support for parameter injection in CDI #30

chkal opened this issue Jul 19, 2020 · 8 comments

Comments

@chkal
Copy link
Contributor

chkal commented Jul 19, 2020

Issue by mvcbot
Thursday Oct 16, 2014 at 17:01 GMT
Originally opened as mvc-spec/mvc-spec#16


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?

@chkal
Copy link
Contributor Author

chkal commented Jul 19, 2020

Comment by mvcbot
Monday Jan 05, 2015 at 18:10 GMT


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.

@chkal
Copy link
Contributor Author

chkal commented Jul 19, 2020

Comment by mvcbot
Monday Mar 09, 2015 at 18:03 GMT


Comment by Santiago Pericas-Geertsen:

Under discussion with CDI spec lead.

@chkal
Copy link
Contributor Author

chkal commented Jul 19, 2020

Comment by mvcbot
Thursday Mar 19, 2015 at 11:00 GMT


Comment by antoinesd:

You'll find my parameter injection POC here: https://github.com/antoinesd/CDI-Sandbox/tree/CDI-1.2/param-inject

@chkal
Copy link
Contributor Author

chkal commented Jul 19, 2020

Comment by mvcbot
Thursday Mar 19, 2015 at 11:28 GMT


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.

@chkal
Copy link
Contributor Author

chkal commented Jul 19, 2020

Comment by mvcbot
Thursday Mar 19, 2015 at 12:17 GMT


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.

@chkal
Copy link
Contributor Author

chkal commented Jul 19, 2020

Comment by mvcbot
Thursday Mar 19, 2015 at 12:25 GMT


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?

@chkal
Copy link
Contributor Author

chkal commented Jul 19, 2020

Comment by mvcbot
Tuesday Jul 14, 2015 at 12:52 GMT


Comment by Manfred Riem:

Jozef, that is indeed correct. Is it possible to get that in the BeanManager API?

@chkal
Copy link
Contributor Author

chkal commented Jul 19, 2020

Comment by mvcbot
Wednesday Mar 30, 2016 at 07:46 GMT


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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant