On 12 Dec 2013, at 17:43, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> 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.
Unfortunately, we do not have resources to invest into such a large piece of work at the moment. It is also not clear to me who would then write the bridge between Guice/Spring & CDI, Guice/Spring and EJB, necessary integration with JNDI and injection in GlassFish, WebLogic... etc. As a JAX-RS reference implementation, we MUST support CDI, EJB and GlassFish as Java EE RI in all our injection-provider configurations. We also MUST support WebLogic as Jersey is fully sponsored by Oracle.
Also, if we would do what you are suggesting, rather than having to worry about integration with a single injection framework we would suddenly have to maintain:
1. Jersey proprietary injection provider SPI - something we wanted to get rid of in the first place
2. HK2 injection provider implementation
3. Guice injection provider implementation
4. Spring injection provider implementation
5. Integration between all the above and a combination of CDI, EJB, JNDI x GlassFish, WebLogic, OSGi, Jetty, Grizzly, Tomcat...
Once again, at the moment, we simply have other priorities and cannot afford allocate the necessary resources into such a big task that is not aligned with our priorities. You should consider HK2 to be our current injection layer and HK2 SPIs are our own SPIs. Using HK2 helps us focus on our core business and let specialized team deal with injection issues. The idea that exposing one more custom injection SPI will solve all the issues is naive. It will not. It will open other ones. We know that as we have been in that situation with Jersey 1.x.
That said, we will continue, together with the HK2 team, investing smaller amounts of our time into investigating what else can be done to improve the situation, but if issues caused by deficiencies in Guice API/SPI should get really fixed, they need to be fixed in Guice.
Howgh,
Marek
>
> 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+%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>
>>>
>>> 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.
>