Dependency injection issue

[cornelcreanga]

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

[cornelcreanga]

hi, any update on this?

[jansupol]

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 import org.glassfish.hk2.utilities.binding.AbstractBinder; with import org.glassfish.jersey.internal.inject.AbstractBinder; in TestContextBinder class. Unfortunately, AbstractBinder is in an internal package in 2.26+, we should revisit that.

[arjantijms]

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,...

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?

[jansupol]

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.

[arjantijms]

The abstraction currently used still reflects HK2 patterns, that may not be available in other DIs, and certainly not in JSR 330.

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.

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.

That's indeed true, so it may not be needed that much in 3.0. Hmmm, choices, choices how to go forward ;)

[cornelcreanga]

confirmed. thanks.

[jansupol]

fixed by #4122