(I'm posting this discussion on the HK2 issue tracker first. If it makes sense, we'll move discussion to the Jersey issue tracker)
I've recently moved away from Dependency Injection towards https://bitbucket.org/cowwoc/servicelocator/wiki/Home
I'm not necessarily advocating you do the same (although...) but this change of perspective gave me some ideas:
Guice cannot delegate to another framework for failed bindings, and the Jersey team refuses to provide the building blocks for creating such bindings. But... what about implementing a Guice Provider on top of HK2's ServiceLocator for each Jersey type (e.g. UriInfo) and bind it like Guice expects?
- Configure HK2 to inject Jersey types. Don't try making it inject Guice types.
- Create one Provider per Jersey-type, built on top of a HK2 ServiceLocator which is passed into the Module.
- At runtime, get your hands on an HK2 ServiceLocator, use it to create a Guice Injector then add a binding to HK2 which delegates to this injector for unknown types.
The beauty of this approach is that it would work for any DI framework, including https://bitbucket.org/cowwoc/servicelocator/wiki/Home
This story isn't complete for two reasons:
- Can we add an HK2 binding for unknown types after the HK2 ServiceLocator is already instantiated? I think so, but we'd need to double check.
- We need to figure out whether GuiceFilter is still needed injecting resources (I suspect it is), or whether we can find a replacement. If we need GuiceFilter then the Jersey team needs to let us pass in a ServiceLocator into the ResourceConfig constructor instead of having ResourceConfig construct its own instance.