On Thu, Oct 31, 2013 at 9:37 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> On 31/10/2013 1:07 PM, Cameron Jones wrote:
>
> The only DI specification which guarantees portability is CDI, and even
> that needs implementation specific code to get up and running.
>
> JSR-330 is non-portable. It consists of some loosely defined annotations
> and some javadoc and that's it. It would be up to an implementation like
> Jersey to provide the portability between DI containers under the
> specification of JAX-RS. That turns JAX-RS into a DI abstraction layer
> which (debatably it already is) imposes much larger requirements on
> implementations.
>
>
> I agree. JSR-330 is a step in the right direction but it is far from
> complete. This is why I advocate that JAX-RS should omit any mention of DI
> and leave it up to JSR-330 and friends to figure this out in the future.
>
> Gili
>
JAX-RS still needs to define how the resource classes are constructed and
then define how the request is dispatched. These are DI features, and
JAX-RS would be a little defunkt without them.
I see there are 3 options available to remedy the DI woes:
1. Integrate JSR-330 into JAX-RS with the rules for delegation to a DI
container.
2. Jersey provides DI though extension modules.
3. HK2-Guice bridge
I prefer 1 as the most flexible and the best end solution across vendors. 2
is an architectural design decision for the Jersey project. 3 is the worst
case because it's largely just a monkey patch and leaves multiple DI
containers in your VM with memory and startup problems.
The current DI state of affairs is reminiscent of the debacle of logging in
Java. Coding to implementations and applying a bridging method between
frameworks leaves a terrible legacy and really hurts the modularity of
libraries.
cam