Guice integration. about hk2

[glassfishrobot]

Reported by @mpotociar

[glassfishrobot]

@tlcksnyder said:
reassign due to Tom leaving Oracle.

[glassfishrobot]

@jwells131313 said:
The implementation of this is mainly done at this point, but I need to create a site for it

[glassfishrobot]

cowwoc said:
jwells,

Did you put up a site?

[glassfishrobot]

aluedeke said:
could we already test the guice integration? would love to use guice with jersey 2

[glassfishrobot]

cowwoc said:
+1. This should ship before Jersey 2.0 is released, not after. I'd even go so far as saying the Jersey 2.0 release should be delayed if that's what it takes.

[glassfishrobot]

@mpotociar said:
I quite strongly disagree. Jersey 2.0 is not going to be blocked by missing Guice integration. HK2 provides all the main features wrt. injection support. So, same as with Jersey 1, community provided the integration after Jersey has been released. If you feel strongly about the integration, give us a hand and contribute.

[glassfishrobot]

cowwoc said:
Marek,

Our goals are the same: we both want to see a successful release of Jersey 2.0.

My fear (which I have stated on the mailing list) is that this and other features will be left out of 2.0 under the assumption that they could be implemented in 2.1 but upon further investigation we will discover that they require an API change which means that they will be left out of 2.x altogether. I am basing this on concrete history of what happened in this and other JDK projects in the past.

I am more than happy to contribute. If you look, you'll notice that I contributed the original Jersey-Guice binding and have posted numerous patches to JIRA. But these contributions cannot happen in a vacuum. The Jersey code-base is large and complex and as a part-time contributor I cannot hope to work productively without the support of a full-time committer such as yourself. I have posted questions and patches both to the mailing list and JIRA in the past and days, weeks and even months went by before I received a reply. If we are to work as a team, I will need quicker turn-around on some of these questions; otherwise, I lose my train of thought. Most of the time I am looking for you to mentor, to make sure I am going in the right direction. I don't want to end up with a design which you are not willing to commit so it'll save both of us a lot of headache if I could have more support up-front.

There are two RFEs I feel very strongly about. Guice support and concurrent unit tests. The latter is much more complex and more important in that I am certain it will require API changes (so deferring to 2.1 isn't possible). What is the best way for us to work productively going forward? Would you prefer me to coordinate work with you over JIRA, the developer mailing list or user list?

Let me know.

[glassfishrobot]

@jwells131313 said:
The HK2/Guice bridge is complete and described at this page:

https://hk2.java.net/guice-bridge/index.html

It is also linked in off of this page:

https://hk2.java.net/integration.html

If people use the Guice bridge and find bugs please open bugs!

[glassfishrobot]

cowwoc said:
jwells,

First of all, thank you for your hard work. I've got some questions regarding the binding you introduced:

1. Instead of using @HK2Inject, couldn't you provide Guice bindings for HK2-injected services? For example, when using Jersey 1.x there is a class called JerseyServletModule that @provides WebApplication, UriInfo, etc... This way when Guice injects UriInfo the provider passes control to HK2 which does the real injection.

2. Is there a benefit to asking users to create HK2-Guice bindings in two steps as opposed to hiding it behind a single method? For example, couldn't you expose the following method instead?

public GuiceBridge.bind(ServiceLocator aServiceLocator, Injector guiceInjector)
{
  GuiceBridge.getGuiceBridge().initializeGuiceBridge(aServiceLocator);
  GuiceIntoHK2Bridge guiceBridge = aServiceLocator.getService(GuiceIntoHK2Bridge.class);
  guiceBridge.bridgeGuiceInjector(guiceInjector);
}

This way users only need to invoke GuiceBridge.bind(aServiceLocator, injector) and they're done.

[glassfishrobot]

@jwells131313 said:
1. Instead of using @HK2Inject, couldn't you provide Guice bindings for HK2-injected services? For example, when using Jersey 1.x there is a class called JerseyServletModule that @provides WebApplication, UriInfo, etc... This way when Guice injects UriInfo the provider passes control to HK2 which does the real injection.

That only works when you know the Type of the thing you are going to be injecting before hand (at compile time). e.g. UriInfo or WebApplication. The only other thing that we could do would be to construct a class at runtime. This would only work for HK2 services that were available before the Injector was created as well, anything added to HK2 dynamically after the Injector was created would not be available. For the last reason alone I question whether or not this is better. However, it is a possible enhancement request for the Bridge if you would like to add it.

2. I can add the method you described to GuiceBridge. This is only one-directional though, but it is a little easier so I'll add it. I think I can also add a bi-directional initializer as outlined in the site, though that one would have to take over creation of the Injector and so would not be as powerful IMO.

[glassfishrobot]

cowwoc said:
1. My experience with Jersey-Guice integration has been that once a user decides they wants to use Guice, they use Guice exclusively. Meaning, I am guessing (to be checked!) that users will never need to configure bind different instances to both HK2 and Guice. If they use the Guice bridge, they do so with the understanding that all future bindings must come from Guice and the bridge will only share the built-in HK2 bindings.

Does that make sense?

2. Yes, we need a bi-directional initializer. Instead of constructing an Injector on our behalf, I recommend exposing a Guice Module (i.e. new HK2IntoGuiceBridge(serviceLocator)) and asking users to pass in a pre-configured Injector.

[glassfishrobot]

@jwells131313 said:
I don't think I understand your point #1, since it is clearly not the case that HK2 can guess what people in their own applications will be using. This must be a general purpose bridge, and hence there are no specific things HK2 could give out.

As for point #2, I do not see a way to add in Bindings to an Injector once the Injector has been created. If there is one, please let me know. What I could do would be to create a child Injector of the first injector, but it would be the case that the Bindings in the first (parent) Injector could not use/see the services from HK2.

[glassfishrobot]

cowwoc said:
1. I'm saying that in my experience a user will not simultaneously configure bindings for HK2, Guice and Spring at the same time. Yes, in theory this could happen, but in practice it will not. Anyway, seeing as @HK2Inject is only needed for inject dynamically-registered HK2 services into Guice (and I don't think this will ever happen) then I'm fine leaving things as-is. My only request is for built-in services (e.g. UriInfo) be injectable using either Guice @Inject or @HK2Inject. That way, users who only dynamically configure services under Guice can inject the built-in types like they used to in Jersey 1.0 (using @Inject). Are you okay with this?

2. You misunderstood. In the documentation you write that HK2 provides a Guice module called HK2IntoGuiceBridge. You also instruct users to create their Injector as follows:

Injector injector = Guice.createInjector(
new HK2IntoGuiceBridge(serviceLocator),
// application modules);

all I'm saying is that you ask users to pass that injector into createBiDirectionalGuiceBridge() instead of passing in ServiceLocator and a list of Modules.

[glassfishrobot]

t.broyer said:
Anyone knows how to use it with Jersey 2.0? Is it at least possible? (I can't seem to find a way to get access to the ServiceLocator from within the ResourceConfig).

[glassfishrobot]

aluedeke said:
i created a small sample project on github which shows a possible way to integrate both frameworks using the work from jwells. checkout https://github.com/aluedeke/jersey2-guice-example

@JWells if you have time could you review it and provide some feedback?

[glassfishrobot]

cowwoc said:
I believe we've got a problem.

The Jersey 1.x mechanism used the following call-flow:

Container
-> GuiceFilter (Guice: initialize request scope)
-> GuiceServletContextListener (Guice: initialize the Guice injector)
-> JerseyServletModule (Jersey: bind Jersey types to Guice module)
-> GuiceContainer (Jersey: redirect incoming requests to resource classes)

The problem is that the above mechanism requires you to construct an Injector before Jersey sees an incoming request, but the new Jersey 2.x requires us the use of ServiceLocator which is only available after Jersey sees an incoming request.

How do we resolve this?

[glassfishrobot]

cowwoc said:
Please reopen this issue until we gain a better understanding of how to use Guice with Jersey 2.x.

[glassfishrobot]

cowwoc said:
I opened a separate issue for guice-servlet integration: https://java.net/jira/browse/HK2-121

The existing unit tests fail to test this functionality and Jersey 2.0 cannot be used with Guice without it.

[glassfishrobot]

@jwells131313 said:
aluedeke, I looked at your example, it is interesting. Have you used the bridge someplace?

[glassfishrobot]

Parent-Task: HK2-57

[glassfishrobot]

Issue-Links:
is related to
HK2-121

[glassfishrobot]

This issue was imported from java.net JIRA HK2-39

[glassfishrobot]

Marked as fixed on Friday, December 6th 2013, 4:24:09 am