users@jersey.java.net

Re: Summary/proposal for spring integration

From: Martin Grotzke <martin.grotzke_at_freiheit.com>
Date: Wed, 09 Apr 2008 11:50:08 +0200

Salut Paul,

On Tue, 2008-04-08 at 11:19 +0200, Paul Sandoz wrote:
> Hi Martin,
>
> Martin Grotzke wrote:
> > 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?
> >
>
> Hmm... perhaps we need to be explicit on three types of scope:
>
> - per web-application
>
> - per request
>
> - don't care
>
> Jersey can inform when it needs a component of a given scope (e.g. for
> resource classes or a message body reader/writer) or inform it does not
> care what the scope is.
Ok. Just to understand: why do you prefer a scope "Don't Care" over
omitting the requirement at all in the method signature (getInstance
without a scope parameter)? My thoughts were, that a method parameter
represents a requirement - and the other way round, if there's no
requirement, one does not need the parameter.

Concerning the Scope enumeration: you mention web-application and
per-request. pre-request is the enum value ApplicationDefined:

   /**
    * Declares that the scope is application defined and instances will
    * be managed by the runtime according to this scope. This requires
    * that a new instance be created for each invocation of
    * <code>getInstance</code>.
    */
   ApplicationDefined

So application-defined would be used for the built in PerRequest
provider and also for application level providers like e.g. PerSession.
Then application-defined is only a part of the scenarios that
ApplicationDefined is used for. Perhaps this should be renamed to s.th.
more appropriate? And I just wonder, if for application-defined scopes
this enum type would need some "hint", which application defined
provider requests some component.

Now thinking about the name for the "don't care" scope... What do you
think about "Undefined"?

I would add this scope in the spring-integration branch then.

>
> But i guess there could be issues if the scope of the thing to inject on
> is not compatible with the scope of the thing that is being injected,
> e.g. a singleton resource with a per-request thing being injected. Not
> sure what we can do about this except say "developer beware!", and in
> such cases one should use the direct IoC injection mechanisms if possible.
Hmm, the scope of the resource might be a constraint in respect to the
scope of injected dependencies, but in consequence a component provider
would have to implement a getInstance implementation for creating a
resource different from a getInstance implementation for creating a
dependency that shall be injected into a resource. Just thinking about
this...
For now I would say that it should be left to the developer, that he has
to configure resource and dependency scopes correctly.

>
>
> > 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.
> >
>
> For general field injection i think you have chosen the right place.
>
> General comment, for errors in the runtime we should throw a
> ContainerException (rather than RuntimeException) so we know it is an
> error associated with the JAX-RS runtime.
Thanx for this hint, changed (not yet committed).

Cheers,
Martin


>
> Paul.
>
> > 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
> >>