On 09/12/2013 3:42 PM, Marek Potociar wrote:
>
>>
>>> <skippable-technical-detail>
>>> As for the issue Guice integration issue, let me recap the broader
>>> perspective - esp. for other observers new to the topic:
>>>
>>> When we started the Jersey rewrite, we knew that most of the time
>>> spent in maintaining Jersey 1.x code has been burned on resolving
>>> Jersey 1.x proprietary injection framework issues, so the decision
>>> was to get rid of the code and use a dedicated provider instead. And
>>> so we switched to HK2 and decided to also delegate any injection
>>> framework integration support to HK2 layer. This works well in most
>>> cases, however in case of Guice we are running into limitations on
>>> Guice end that we are not able to resolve without help from Guice
>>> developers, and they do not seem to be willing to make any changes
>>> in Guice at the moment. So we're quite stuck. To be specific, Guice
>>> does not seem to support delegation of resolving an
>>> @Inject-annotated injection point in Guice-managed POJOs to other
>>> framework (in our case to HK2). So while HK2-managed POJOs can
>>> inject Guice-managed POJOs into their fields (since HK2 has the SPI
>>> for delegating the injection resolution to Guice), the opposite way
>>> does not work. Guice-managed POJOs cannot inject any HK2-managed
>>> POJOs into @javax.inject.Inject annotated injection points as there
>>> is no injection resolver delegation SPI for @javax.inject.Inject in
>>> Guice. The only available workaround at the moment is to use
>>> @Hk2Inject instead of @Inject in Guice-managed POJOs in those places
>>> where HK2-based components have to be injected.
>>> </skippable-technical-detail>
>>
>> Actually, @Hk2Inject does not work for this common
>> use-case:https://java.net/jira/browse/HK2-139
>
> IIUC, this is the one aspect of the issue in Guice that I'm talking
> about - Guice is not calling the HK2 in this case. There's nothing we
> can do AFAIK unless Guice folks fix the problem. Please correct me if
> I'm missing something.
>
There is something we can do. As proposed at
https://java.net/jira/browse/JERSEY-1950?focusedCommentId=371416&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_371416
we can expose factories necessary for Guice to do 100% of the injection,
and I'll provide the necessary Guice module to do the binding instead of
HK2. I think Jersey core should depend exclusively on JSR-330 (only do
injection) and delegate DI configuration to external/optional modules.
There would be one such module for HK2, Guice and Spring. I suspect this
will require a small number of changes on your end, the main one being
that the DI will inject Application instead of Application instantiating
the DI engine. Once we're over that hump, the rest should be easy.
I'm going to need your help with these changes because I'm not sure how
to implement DI injecting Application instead of Application creating
the DI.
And as I mentioned below, there are many outstanding Spring-support
issues. I believe this approach would fix those problems as well.
Gili
>
>> I looked through JIRA and found the following Spring-related
>> issues:https://java.net/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+JERSEY+AND+%28summary+~+spring+OR+description+~+spring%29+AND+resolution+%3D+Unresolved+AND+affectedVersion+in+%28%222.4.1%22%2C+%222.4%22%2C+%222.3.1%22%2C+%222.3%22%2C+%222.2%22%2C+%222.1%22%2C+%222.0%22%29+ORDER+BY+key+DESC
>> <https://java.net/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+=+JERSEY+AND+%28summary+%7E+spring+OR+description+%7E+spring%29+AND+resolution+=+Unresolved+AND+affectedVersion+in+%28%222.4.1%22,+%222.4%22,+%222.3.1%22,+%222.3%22,+%222.2%22,+%222.1%22,+%222.0%22%29+ORDER+BY+key+DESC><https://java.net/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+JERSEY+AND+%28summary+%7E+spring+OR+description+%7E+spring%29+AND+resolution+%3D+Unresolved+AND+affectedVersion+in+%28%222.4.1%22%2C+%222.4%22%2C+%222.3.1%22%2C+%222.3%22%2C+%222.2%22%2C+%222.1%22%2C+%222.0%22%29+ORDER+BY+key+DESC
>> <https://java.net/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+=+JERSEY+AND+%28summary+%7E+spring+OR+description+%7E+spring%29+AND+resolution+=+Unresolved+AND+affectedVersion+in+%28%222.4.1%22,+%222.4%22,+%222.3.1%22,+%222.3%22,+%222.2%22,+%222.1%22,+%222.0%22%29+ORDER+BY+key+DESC>>
>>
>> I would like to hear from multiple people using Jersey with Spring
>> because it is genuinely not clear to me whether the HK2-Spring bridge
>> suffers from the same design-level problems as the HK2-Guice bridge
>> or not. Right now I am under the impression that both Guice and
>> Spring support has serious problems.