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