On Mar 26, 2008, at 9:02 AM, Paul Sandoz wrote:
> 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.
>
+1 to Paul's points, I think this needs quite a bit more work before
we should look at standardizing something in this area - anything we
come up with now is likely to be sub-par and then we'll be stuck with
it. I'd rather we continue to experiment in implementations for now
and only try to standardize an API once a consensus emerges as to a
fully workable approach.
I propose to close issue 9:
https://jsr311.dev.java.net/issues/show_bug.cgi?id=9
With status "LATER".
Marc.
> 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
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.