users@jersey.java.net

Re: Summary/proposal for spring integration

From: Martin Grotzke <martin.grotzke_at_javakaffee.de>
Date: Fri, 04 Apr 2008 19:46:28 +0200

Hi Paul,

I just continued with parts of the spring integration.

The ResourceContext is implemented now, so that resource classes can
pull dependencies from it. The Resourcecontext is injected if the field
is annotated with @Context.

Concerning case 2 (injecting external dependencies based on some
annotation) please see below..

On Wed, 2008-03-26 at 12:01 +0100, Paul Sandoz wrote:
> Martin Grotzke wrote:
> >> I see. I am not sure @Resource is the right thing to use in all
> >> cases. Note that for Jersey injected stuff on fields we stopped using
> >> @Resource and switched to using @Context because we were not
> >> conforming to @Resource with regard to it's use as it pulls in other
> >> EE 5 stuff (like JNDI).
> >>
> >> Hmmm... i wonder if we could reuse @Context instead of created a new
> >> annotation?
> > So instances for @Context-annotated fields or method arguments would be
> > pulled from the ComponentProvider?
> >
>
> Yes, if Jersey does not know what to do with them.
I just tried to implement this in the spring branch, then I realized,
that the ComponentProvider.getInstance expects not only the type/class,
but also the scope - which is not known at this place, as it's
completely left to the application which scope the external dependency
has.

What would you suggest as solution for this? Would you say the
ComponentProvider should get another getInstance with just the class to
support this case?

You can have a look at WebApplicationImpl.injectResources as it's
handled right now, this is just a temporary solution to test if it
works, perhaps you want to take a look at it.

Cheers,
Martin



>
>
> > ResourceProvider sounds well (or ResourceFactory?). Hmm, just thinking
> > again about this - it's not only about resources (resource classes in
> > the REST world), but one might also pull other dependencies from the
> > ComponentProvider using this, right? E.g. some prototyped (perRequest)
> > scoped bean that is instantiated by the IoC-container (I don't have a
> > good example, sorry). So perhaps it should not be named too resourceFul,
> > but perhaps s.th. like BeanProvider or BeanFactory?
> > What would be the difference between the ComponentProvider and the
> > ResourceProvider/BeanFactory? Just to get a better idea of what it
> > is... :)
> >
>
> "ResourceProvider" would only return instances of resource classes.
> There is some additional functionality in the management of resource
> class life-cycle that is not available when using ComponentProvider e.g.
> the per-request life-cycle chooses the constructor and constructor
> parameters are extracted from the HTTP request and injected as method
> parameters. Someone may develop their own provider that stores resource
> classes on the servlet HttpSession.
>
> If a general instance of something is required then perhaps it is best
> to use existing IoC mechanisms ? (in addition to allows injection of
> ComponentProvider).
>
> BTW feel free to use the Jersey wiki [1] to capture the Spring
> requirements you noted in a previous email.
>
>
> > Just to throw in an alternative for the existing ResourceProvider: what
> > about ScopedResourceProvider or ScopedResourceFactory?
> >
>
> Thinking some more the *Provider fits naming scheme with the SPI stuff
> that provides to the Jersey runtime. I think anything that the developer
> would commonly use would be better named to something else, for example
> ResourceContext would be a better fit:
>
> public interface ResourceContext {
> <T> T getResource(Class<T> c);
> }
>
> Paul.
>
> [1] http://wikis.sun.com/display/Jersey/IoC+utilities
>