On 18 Dec 2013, at 21:15, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> On 18/12/2013 12:13 PM, Marek Potociar wrote:
>>
>> On 12 Dec 2013, at 17:43, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>>
>>> 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...
>
> The Jersey team wouldn't have to maintain any of this.
>
> #1: Why would we need such a thing? I never asked for this.
Ok, I must have misunderstood. You want to provide implementations for Factory from Guice API. I get it now, sorry for the confusion. Well, good luck, fingers crossed. :)
> #2 would be contributed and maintained by the HK2 team.
Based on how I understand now the #1 above, #2 is what we have right now. We will maintain it in Jersey, no problem.
> #3 would be contributed and maintained by Guice users such as myself.
Ok, it may be a standalone extension then.
> #4 would be contributed and maintained by Spring users (there are plenty on the list).
Ok, same as above.
> #5: I don't understand what sort of integration you had in mind. Why would you ever need/want to integrate Guice and CDI?
Why? To be compliant with JAX-RS spec. Or do you think that there are no users who use Spring or Guice with a Java EE application server? Well there are. Plenty.
> In any case, the only thing I'm asking you to do is ensure that the community can implement add-ons for other DIs (provide the descriptors/factories to bind to). The only integration you'd have to officially support is the one that you already do.
How am I supposed to ensure that?? Sorry, but this is a little bit ridiculous. I do not have the community on my command ...as much as I would occasionally like to :)
>> 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.
>
> This view is problematic for two reasons:
> The top 2 most requested features involve Spring and Guice support. We're talking about 4-5x more votes than anything else.
> I feel that you are misconstruing or misunderstanding the amount of work that is involved. I am not asking you to do half the things you mentioned above. Let's make sure we're in agreement on the work items before deciding on this proposal.
Except for #5 where I simply cannot make guarantees on behalf of the Jersey community, I agree.
>> 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.
>
> Translation: this issue will never get fixed. You will find that Guice, Spring, Dagger and the various other DI frameworks do not (and will not) provide the kind of SPI you are asking for. Frameworks like Dagger forbid the use of Reflection (for good reason) making it impossible for them to add the functionality you are asking for. This points to a faulty assumption on Jersey's part, not the DI frameworks.
Thanks for sharing your point of view.
Marek
>
> Gili