-
Notifications
You must be signed in to change notification settings - Fork 351
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
Dependency injection issue #4026
Comments
hi, any update on this? |
During work on 2.26, Jersey tried to separate its injection framework from an implementation. The idea is to be able to use various DI frameworks, HK2, CDI, Spring,... This is not finished yet, currently, hk2 is still the main injection framework, some extensive work has been done on CDI, and the work on others has not started yet. For this, Jersey introduced an abstraction to binders. It no longer uses the HK2 binder, it uses Jersey specific Binder. So, for your example to work again, please replace |
Isn't that a bit like logger frameworks, where e.g. SLF4J abstracts over other loggers, including other abstractions over other loggers? Maybe externalising such work in say a SDIF4J library makes it somewhat more manageable? On the other hand, wasn't JSR 330 supposed to be the DI facade, being supported by all of HK2, Spring, CDI and even Guice? |
Jersey since 2.0 was HK2 dependent, it used HK2 specific objects, such as ServiceLocator or Binder. The abstraction currently used still reflects HK2 patterns, that may not be available in other DIs, and certainly not in JSR 330. It could be a good idea to externalise abstractions in an "SDIF4J", but since JAX-RS 3.0 is to be CDI centric, we will see how much space is there to optionally support the other DIs. |
This is quite interesting by itself, since there was an earlier concern that JSR 330, being so minimal, wasn't perhaps entirely practical to indeed function as a "SDIF4J". Maybe there's room for a JSR 330 v2, which actually could be used in practice to abstract over HK2, Spring, CDI and Guice.
That's indeed true, so it may not be needed that much in 3.0. Hmmm, choices, choices how to go forward ;) |
confirmed. thanks. |
fixed by #4122 |
Hello,
One of our internal library fails after moving from spring boot 1.5.12 (jersey 2.25.1) to spring boot 2.1.1 (jersey 2.27). I've created a very simple project showing the problem:
https://github.com/cornelcreanga/jersey-binder-bug
To reproduce it: run the Application class and notice the NPE. Go to pom.xml, change spring boot from 2.1.1 to 1.5.12 and run it again - the dependency is injected as it should.
Tracking the problem I have the impression that the problem is in the class org.glassfish.jersey.internal.util.collection.Cache/apply but I'm not 100% sure.
Thanks
cc @razmanolescu @lucianfelix @margelatu
The text was updated successfully, but these errors were encountered: