Dynamically registered Provider classes create thousands of ServiceLocators

[mpfz0r]

While tracking down a performance problem (Graylog2/graylog2-server#5669)
I noticed that Jersey was creating thousands of ServiceLocators in our application.
Since we are creating a GuiceBridge for each Locator, a lot of time is spent filling the cache
of the GuiceToHk2JitResolver.

The root of the problem is that Jersey creates a ServiceLocator for each Resource
in case of a dynamically registered Provider class:
https://github.com/eclipse-ee4j/jersey/blob/master/core-server/src/main/java/org/glassfish/jersey/server/model/ResourceMethodInvoker.java#L229

What's the reason behind this? Why do we need a separate DI context in this case?

I also build a small demo app that exposes the problem:
https://github.com/mpfz0r/jersey-di-issue

[senivam]

Jersey acts so per JAX-RS specification (https://download.oracle.com/javaee-archive/jax-rs-spec.java.net/jsr339-experts/att-3593/spec.pdf): chapter 3, paragraphs 3.1.1 Lifecycle and Environment and 3.1.2 Constructors

Closing the issue as expected behavior.

[mpfz0r]

Jersey acts so per JAX-RS specification (https://download.oracle.com/javaee-archive/jax-rs-spec.java.net/jsr339-experts/att-3593/spec.pdf): chapter 3, paragraphs 3.1.1 Lifecycle and Environment and 3.1.2 Constructors

Thanks,
after reading this, I still fail to understand why each Resource needs a separate ServiceLocator.
Even if this is not a bug, the current implementation has a huge performance impact in the use case
I described above.