On Fri, Nov 1, 2013 at 4:12 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> 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 meant wrt dynamic dispatching where subresources require injection.
>
>
> 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).
>
Well, it would require work on the part of HK2 and/or Guice.
>
> 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?
>
>
I meant how JAX-RS would interact with JSR-330 annotations, so some form of
programmatic lookup would probably be the first. I don't really know the
details, the JSR-339 group would probably have a better idea.
For 2, i was thinking along the lines of the Jersey v1 extension model.
>
> 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
>
cam