On 07 Nov 2013, at 17:28, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> 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.
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.
>
>>>> 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.
Well, I have no more influence on JSR-330 owners than you. JCP is an open, democratic community, not a dictatorship. You cannot force people to give up control of their own work and intellectual property if they do not want to.
> 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?
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.
Anyway, we're getting side-tracked. I do not want to discuss JSR-330 & JCP issues in this mailing list. Let's cut it here.
Marek
>
> Gili