You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to @Inject some bean into a JAX-RS resource using Weld.
Jetty is configured to interact with Weld, and this works: I can inject beans (and even use @Transactional services) into a normal servlet.
But when injecting into a JAX-RS resource, HK2 tells me: org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection.
Following the instructions here, I do not depend on org.glassfish.jersey.ext.cdi:jersey-weld2-se, but I do depend on org.glassfish.jersey.inject:jersey-hk2.
Related question: how is HK2 supposed to know that it must delegate injection to Weld? I did not tell anthing about Weld to Jersey. I suspect this explains the failure.
Is there an example I could use to check for differences? (I have looked at the helloworld-cdi2-se and cdi-webapp examples but they do not seem to let HK2 interact with Weld.)
You may checkout this commit to reproduce the problem.
Thanks for any pointer.
The text was updated successfully, but these errors were encountered:
I just realized, re-reading the mentioned issue (#4121), that adding org.glassfish.jersey.ext.cdi:jersey-cdi1x solves the problem. Great!
I still have a few questions, or suggestions to improve the documentation.
(As in the original post) how does HK2 know that it must delegate injection to Weld?
Should I also depend on org.glassfish.jersey.ext.cdi:jersey-cdi1x-servlet? More generally, when must it be included, and when not?
The documentation currently does not state clearly, IMHO, when HK2 must be included as a dependency. Section 29.1.2, Breaking Changes - Injection Manager states: “InjectionManager contains a mechanism for registering DI specific injection bindings, in case the application uses CDI, developers should use CDI mechanism, in case the application uses HK2, developers should configure HK2”, which initially let me believe that in my case, I had to not depend on HK2. Also: “If the internal Jersey injection API is to be backed by HK2, since 2.26, the (…) HK2 support module is required”. But the related issue says the contrary, which put me on the right track.
Similarly, I found it hard to understand, even after multiple readings of the Chapter Jersey CDI Container Agnostic Support, that in my case, jersey-weld2-se must not be included in the dependencies.
There are two possible environments for Jersey: SE, and provided ServletContainer/EE.
When Jersey is started in the SE environment, such as atop Grizzly, there is no CDI and CDI needs to gets started. Currently, only Weld is supported, and for the SE environment, jersey-weld2-se is to be used to have CDI injecting properly. jersey-cdi1x-servlet should not be used there. Without CDI, HK2 is required in the SE env for Jersey to inject.
When Jersey is started in the servlet container (such as Jetty), Jersey needs HK2. If CDI is provided by the EE env, jersey-cdi1x-servlet, is required, too. jersey-weld2-se should not be used in the EE environment.
I would like to
@Inject
some bean into a JAX-RS resource using Weld.Jetty is configured to interact with Weld, and this works: I can inject beans (and even use
@Transactional
services) into a normal servlet.But when injecting into a JAX-RS resource, HK2 tells me:
org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection
.Following the instructions here, I do not depend on
org.glassfish.jersey.ext.cdi:jersey-weld2-se
, but I do depend onorg.glassfish.jersey.inject:jersey-hk2
.Related question: how is HK2 supposed to know that it must delegate injection to Weld? I did not tell anthing about Weld to Jersey. I suspect this explains the failure.
Is there an example I could use to check for differences? (I have looked at the helloworld-cdi2-se and cdi-webapp examples but they do not seem to let HK2 interact with Weld.)
You may checkout this commit to reproduce the problem.
Thanks for any pointer.
The text was updated successfully, but these errors were encountered: