users@jersey.java.net

Re: Summary/proposal for spring integration

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 09 Apr 2008 13:01:02 +0200

Martin Grotzke wrote:
>> 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.
>

I was assuming "Undefined" is still a requirement :-) for both the
implementor and the callee. It is whether one chooses to be explicit or
implicit about it. IMHO being explicit declares clearer and consistent
semantics for implementors of ComponentProvider and the Jersey code that
uses the ComponentProvider interface.


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

Yes, because the intention is there will be more than one instance
created (and managed) per-web application.


> Then application-defined is only a part of the scenarios that
> ApplicationDefined is used for.

I see what you mean, it is really about Jersey defining the scope, where
Jersey is the (web) application.


> Perhaps this should be renamed to s.th.
> more appropriate?

Yes, lack of imagination on my part. Perhaps if i enumerate things with
some words a better naming scheme might be apparent:

       WebApplication === singleton (per web application)
                          if there are two separate web applications
                          running in a VM with a resource class
                          registered in both then each web application
                          must get a different instance of the resource
                          class.
   ApplicationDefined === new instance, let jersey manages the scope of
                          the instance
            Undefined === Jersey does not care what the scope is, let the
                          component provider decide.


> And I just wonder, if for application-defined scopes
> this enum type would need some "hint", which application defined
> provider requests some component.
>

For that scope Jersey requires a new instance, i am not sure how passing
a hint on why it needs a new instance will help.

IMHO the way to do a fully compatible IoC scoped resource class is to
specify a resource provider that always uses the "Undefined" scope. Then
one can specify it to be the default provider for all resources.



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

Yes.


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

Agreed.

Paul.

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109