users@jersey.java.net

[Jersey] Re: jersey-guice based on spring-guice

From: cowwoc <cowwoc_at_bbs.darktech.org>
Date: Tue, 12 Nov 2013 16:59:01 -0500

Hi Marek,

On 12/11/2013 8:02 AM, Marek Potociar wrote:
>>>> Actually, it is very different for us. When we ask for anything
>>>> from Guice folks, we get rejected. When we ask for anything from
>>>> HK2, our requests get almost always accepted. Also, we have commit
>>>> rights in HK2 and are able to get a quick review & approval from
>>>> HK2 team for any last-minute fixes if necessary. Also, HK2 is core
>>>> part of GlassFish which makes our GF integration a lot easier.
>> Isn't HK2 development led by employees that are paid by Oracle, at
>> least in some part?
> Yes. Does the question relate to this discussion?

Well, yes. You wrote "When we ask for anything from Guice folks, we get
rejected. When we ask for anything from HK2, our requests get almost
always accepted." The fact that you both work for the same company is
relevant to the argument that "requests from HK2 almost always get
accepted" :) You can hardly expect the same to be true across company
lines, in a mature open-source project.

>> 2. Just because you get rejected when speaking to Guice doesn't mean
>> I'll get a different response when I ask. I don't think they are
>> treating you any different from anyone else. From their point of
>> view, Guice is a mature product that doesn't require any major
>> changes. More practically, Guice is "good enough" for Google's
>> own development so they have less incentive to add any more
>> features. I agree with you that there is plenty of remaining
>> problems with Guice and they should be more receptive to issues
>> brought up by the community.
>>
> Our major problem with Guice is that we (or, more precisely, the HK2
> team) are not able to figure out how to convince Guice to delegate
> injection of some of the @Inject-annotated injection points to a 3rd
> party provider (HK2). This use case does not seem to be covered, IIUC.

Correct. This feature is not supported and there isn't enough community
interest in supporting it. No one is willing to work on providing
additional SPI hooks, especially since such hooks are only really useful
for users of a different DI. I'd be surprised if Spring was much
different in that respect. The HK2 bridge requires changes to the guts
of Guice and Spring, as opposed to layering something on top of their
existing (unmodified) implementations.

>> I'm just telling you how things are: *if* we develop an extension
>> of JSR-330, prove that it works, then come to Guice and ask them to
>> implement it... that's one thing. If we come to them and ask for
>> multiple features individually that together add up to an extension
>> of JSR-330 they're going to have much less incentive to go with it.
>> It's kind of like Jersey development, you are much more receptive to
>> pull requests than bug reports :)
>
> I am certainly not trying to stop you from implementing a Guice
> extension. :)

Maybe not intentionally, but you kind of are :) When you took away the
IoC hooks that existed in Jersey 1.x you prevented me from providing
Guice support. The current mechanism (IoC bridge over HK2) is at a dead
end. The sooner we agree on that point, the sooner we can begin
evaluating alternates.
The JCP rules and the license terms which you accept when you download
JSR-330 APIs. This is btw. good thing - the rules protect the JSR owner
from people who would try to fork a standard API. However if the owner
is inactive, then the JSR suffers.

>> I think you misunderstood what I am proposing. I'm not asking you to
>> fork JSR-330 and then publish a new version of it in spite of the
>> original author's wishes. I'm asking you to fork JSR-330 and publish
>> it as JSR-9231 (changing package names and everything, if needed). Do
>> JCP rules really prevent this?
>
> Yes, IIUC. Otherwise JSR-299 (CDI) would have done it and would not
> need to "invent" their own javax.enterprise.inject package...

We don't need to reuse anything from JSR-330. We can just create a new
"org.glassfish.jersey" package and start defining classes there. We can
them implement the interfaces for HK2, Guice, Spring and be done with
it. The JSP can then publish a de-facto standard with existing
implementations.

Gili