On 18/12/2013 12:13 PM, Marek Potociar wrote:
>
> On 12 Dec 2013, at 17:43, cowwoc <cowwoc_at_bbs.darktech.org
> <mailto: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.
#2 would be contributed and maintained by the HK2 team.
#3 would be contributed and maintained by Guice users such as myself.
#4 would be contributed and maintained by Spring users (there are plenty
on the list).
#5: I don't understand what sort of integration you had in mind. Why
would you ever need/want to integrate Guice and CDI? 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.
> 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:
1. The top 2 most requested features involve Spring and Guice support.
We're talking about 4-5x more votes than anything else.
2. 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.
> 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.
Gili