users@jersey.java.net

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

From: cowwoc <cowwoc_at_bbs.darktech.org>
Date: Thu, 07 Nov 2013 11:28:37 -0500

On 07/11/2013 11:08 AM, Marek Potociar wrote:
> On 05 Nov 2013, at 22:46, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>
>> Marek,
>>
>> On 05/11/2013 3:47 PM, Marek Potociar wrote:
>>> Hello Gili,
>>>
>>> Trying to get the community organized and involved in contributing improvements to Guice and Spring support in HK2 and Jersey 2 is the right step. Please feel free to contribute any new features and/or improvements to current support.
>> Sorry, but I believe we're beyond this point. We (those of us who want to use Guice and Spring) have pretty much established that the Jersey 2.0's design prevents us from using Guice and Spring. The only way we will solve this problem is through open dialogue (on the mailing list or online chat). The very first thing we need to establish is what to do on a design level. Creating push requests beforehand is a waste of everyone's time.
> Note that this needs to be done primarily at HK2 level. The reason why we switched to HK2 from our proprietary injection implementation is that we do not want to be in business of providing our own injection framework.
Marek,

I understand. I have no desire for you to provide your own injection
framework, but depending *directly* on HK2 is no different than
depending on Guice or Spring directly. I'm simply asking for Jersey to
depend on an interface instead of a concrete implementation.

>>> Also, support for Spring and Guice was not the primary release or feature driver for Jersey. JAX-RS 2.0 support and releasing JAX-RS 2.0 RI was the primary motivation for the earliest possible release.
>> I totally agree. What I disagree with is JAX-RS (and Jersey more specifically) mandating specific DI behavior. I argue that JAX-RS should not discuss DI at all. Jersey should provide building blocks needed by DI integrators so that end-users can use HK2, Guice, Spring, or whatever else they wish without having to learn yet another DI framework.
> Talk to Guice guys and convince them to give up their JSR-330 ownership. JCP community is in a stale mate currently wrt. DI spec - we cannot extend the existing DI API with a new, standard (long needed) injection binding API without having the ownership of JSR-330, but the current owners do not seem to be willing to give up that ownership and neither they seem to have any plans to for making any updates to the spec. (FYI, the current plan is to deliver these missing APIs as part of CDI 2.0)

That's a non-starter. If you couldn't do it, I won't be able to either.
I don't think we really need this though.

What prevents us from forking JSR-330 into a private namespace and, if
this experiment works out, publish a separate JSR which standardizes
this work?

Gili