Re: JSR311: resource factories & integration

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 26 Mar 2008 14:02:07 +0100

Hi Dhanji,

I agree on the benefits. In my experience with Jersey it is not so
simple as you propose. I think it requires some more time to prototype
and it is not ready for such standardization.

Jersey provides something called ComponentProvider that is a super set
of what you propose. It works very well for singleton, and per-request
resource classes with zero parameter constructors, and people have
experimented successfully with Spring, Guice and most recently WebBeans.
But, there are issues and there are on-going detailed discussions on the
Jersey users list about Guice and Spring, and best way to support
complex scenarios.

We are very much finding our feet, experimenting, and often hitting
limitations in IoC frameworks... Spring especially is complex so we
could be missing some aspects but quite a few eyes have looked at it...

...for example, one particular tricky issues is that of per-request
resources and constructors with JAX-RS constructor parameters where the
IoC is responsible for instantiation. Developers have hit limitations
with Spring and Guice.


Dhanji R. Prasanna wrote:
> Hi
> I would like to resurrect my proposal several months ago for a pluggable
> factory for creating resource objects. I believe it had some support at
> the time, but the effort may have been waylaid by parallel work on a
> common ioc standard (?), which has since stalled.
> The benefits are numerous:
> - make it easy to integrate dependency injectors like Guice, spring,
> etc., in any environment
> - take advantage of scoping and other lifecycle provided by these
> external frameworks
> - take advantage of aop and interception provided by these frameworks
> - allow the possibility of constructor injection (can set final fields)
> and remove the objectionable no-arg constructor mandate
> The API is simple:
> public interface ResourceProvider {
> <T> T get(Class<T> clazz);
> }
> And can be registered once across the entire app. This can be made more
> generic and encompass Contexts too (replacing the current
> ContextResolver<T>).
> Dhanji.

| ? + ? = To question
    Paul Sandoz