On 18/12/2013 4:04 PM, Marek Potociar wrote:
>
> On 18 Dec 2013, at 21:15, cowwoc <cowwoc_at_bbs.darktech.org
> <mailto: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
>>> <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
>>>> <https://java.net/jira/browse/JERSEY-1950?focusedCommentId=371416&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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. :)
Just to be 100% sure we're on the same page: Right now you implement
some Factory for (say) UriBuilder and bind it into HK2. I'm asking you
to expose these factories in an SPI package. The Guice, Spring, Dagger
extensions would then come in and provide a Guice, Spring, Dagger
configuration that binds those factories in the Guice, Spring,
Dagger-specific way. Jersey's commitment is two-fold:
1. Expose Factory implementations (the ones that you already have for HK2).
2. Use (only) JSR 330 to inject them.
Where we might run into trouble is #2. Do you use any HK2-specific
annotations/features at injection time?
>> #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.
As far as I understand it, JAX-RS does not specify which DI
implementation you must support under these platforms. I'm simply saying
that you continue with the status quo (provide support for Hk2) and let
the community provide add-on modules for other use-cases. The only thing
they'd need from you is the DI factories mentioned above.
>
>> 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 :)
I suspect we're having a misunderstanding again. The only thing I'm
asking you to do is release the aforementioned DI factories. Nothing else.
>
>>> 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.
>>
> Except for #5 where I simply cannot make guarantees on behalf of the
> Jersey community, I agree.
So, I think we're in agreement.
Gili