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.
>
> On 05/11/2013 3:47 PM, Marek Potociar wrote:
>> P.S. As much as I understand why people using Spring and Guice are upset about this, I still do not think it was a mistake to release Jersey 2 without a Spring and Guice support. Jersey now provides JSR-330 injection (via HK2) without any need for Spring or Guice.
>
> I don't understand. Both Guice and Spring implement JSR-330. What do Jersey users gain by the forced use of HK2 as the sole DI implementation?
See above, We do not want to be in business of providing injection implementation. Historically, we had to spend most of our available development resources in maintaining and patching our Jersey 1.x injection framework wrt. integration with Guice and Spring. Jersey is however primarily a RESTful services framework, not a DI container. We want to be able to focus primarily on features around RESTful services, not around dependency injection.
>> 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)
Marek
>
> Gili