dev@jsr311.java.net

Re: JSR311: resource factories & integration

From: Bill Burke <bburke_at_redhat.com>
Date: Wed, 26 Mar 2008 09:15:20 -0400

I just wanted to add that I also started with a similar simple interface
  to Dhanji.

public interface ResourceFactory {

    Class getScannableClass();

    Object create();
}

But at that time I didn't support field and constructor injection. Once
I put that in, I had to expand the SPI significantly.



Paul Sandoz wrote:
> 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.
>
> Paul.
>
> 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.
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com