On 01/11/2013 11:56 AM, Cameron Jones wrote:
> 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.
How they are constructed? Provide POJO classes with public constructors
and let us figure out the rest. Guice/Spring/HK2 integrators would then
provide DI-specific configuration that would inject those classes with
the right arguments. Here is what end-users would do for Guice:
Injector injector = Guice.createInjector(new JerseyModule(), ...
other modules);
In the above example, JerseyModule is the DI-specific configuration that
a Guice integrator would provide. That's what we had for Jersey 1.0 and
it was very easy to use.
What do you mean by "how the request is dispatched"?
> 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.
Currently #3 is not even technically possible (though I will keep on
exploring the possibility).
Help me understand #1 and #2. For #1 what do you mean by "rules for
delegation to a DI container"? For #2 what would an extension module
contain?
> 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.
Agreed 100%.
Gili