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
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