users@jersey.java.net

[Jersey] Re: Proposal: DI abstraction

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Mon, 11 Nov 2013 13:50:06 +0100

Hi Gili,

First of all, a few comments:

1. As you correctly mentioned, JSR330 API should serve as the only internal contract for injecting information.
2. Jersey should not get back into the business of designing and maintaining it's own injection binding APIs. (Note that as you get deeper into the problem and start looking at some extensions that leverage the ability to bind new types, you will find it difficult to meet this requirement).
3. The solution MUST work with GlassFish - including integration with CDI, EJB etc.
4. You may first need to start with implementing support for Jersey RequestScope (and RequestScoped).

Here's the pointer to the requested UriInfo implementation:
https://github.com/jersey/jersey/blob/master/core-server/src/main/java/org/glassfish/jersey/server/internal/routing/UriRoutingContext.java
Here is the binding into HK2:
https://github.com/jersey/jersey/blob/master/core-server/src/main/java/org/glassfish/jersey/server/internal/routing/RouterBinder.java

The UriRoutingContext class is injected and used by internal Jersey request routing runtime components as well as it is proxied by HK2 to be injectable outside of the Jersey request scope.

HTH,
Marek

P.S. IMHO, I still think that a more viable way would be to get in touch with HK2 folks and work with them on resolving issues that cause problems in their Spring and Guice integration. That is the right layer IMO to address this type of problem. Once that is solved, the task of supporting Guice and Spring in Jersey would be solved without the need for heavy changes (that would require long & detailed reviews) in Jersey code.

On 08 Nov 2013, at 17:20, cowwoc <cowwoc_at_bbs.darktech.org> wrote:

> Hi,
>
> I propose going through the Jersey source-code iteratively, replacing all instances where it interacts with HK2 directly (e.g. by referencing ServiceLocator) and replacing it with some interface. I would then provide reference implementations for HK2, Spring, Guice that implement that interface. I believe we'll need to do the following:
> Provide an interface just for injection. I believe JSR-330 already covers this, but if we need anything more we'll provide our own interface.
> Instead of pushing bindings from Jersey into HK2, provide building blocks (POJO classes) for constructing built-in types (e.g. UriInfo). Then provide HK2, Guice, Spring specific code that would configure each specific DI to inject using these blocks.
> To begin this discussion, I'd like to take one built-in type (is UriInfo a good start?) and look at what is needed to construct it without DI. Marek, can you provide some details on this end?
>
> Thanks,
> Gili