It's just unacceptable that Jersey 2 forces end-users to use an arbitrary
DI framework.
This seems more a "corporate political decision" than a "well
thought architectural decision".
--
D. Reinert
On Mon, Oct 28, 2013 at 8:24 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> On 28/10/2013 1:36 PM, Cameron Jones wrote:
>
>> JSR-330 is a bit light-weight and doesn't specify how applications are
>> configured. This would mean that Jersey would have to integrate with every
>> DI container to configure itself.
>>
>
> Jersey 1.0 exposed a DI abstraction layer for functionality it
> depended upon. Guice and Spring then implemented those interfaces, and
> everything worked well (this was before JSR 330 even existed). Jersey 1.0
> never needed to "configure" the DI. It just exposed providers for the
> built-in types (like UriInfo) and the DI implementation used them to inject
> those types.
>
>
> Also, JAX-RS has some of it's own non-standard DI rules which wouldn't be
>> definable without customizations to injection processing. This would also
>> need to be defined per-container.
>>
>
> What do you mean? Can you give an example?
>
>
> At what point does JAX-RS stop and the generic definition of DI
>> containers begin?
>>
>>
> Jersey 1.0 did a pretty good job. We should pick up where it left off
> and take it to the next level. Depending on HK2 directly shifts the burden
> from a small number of Jersey committers to a large number of end-users.
> Guice/Spring weren't designed to for integration into 3rd-party DI
> frameworks. Their design (quite reasonably) assumes the use of one DI
> framework at a time. I have tried integrating Guice and HK2 for weeks now
> and it doesn't look like it's technically possible.
>
>
> JAX-RS DI was discussed by the JSR expert group, and they found the
>> options available to either be lacking in features (JSR-330) or overkill
>> with redundant features (JSR-299), see slide 59:
>>
>> http://www.slideshare.net/**arungupta1/jax-rs20<http://www.slideshare.net/arungupta1/jax-rs20>
>>
>
> I advocate using as much of JSR330 as possible, and filling the
> remaining gaps using a thin abstraction layer. Then we implement the DI
> interface once per DI framework and we're done. Jersey codes against a DI
> abstraction. Users code against Guice/Spring directly (lower learning
> curve!). Everyone is happy. We would also be able to leverage the existing
> Spring/Guice implementations from Jersey 1.0.
>
> Gili
>