On Wed, 2008-04-09 at 13:01 +0200, Paul Sandoz wrote:
> 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.
Ok, thanx for this clarification.
>
>
> > 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.
Yes, this is an issue of wording/terminology. I thought an application
would the users application and not be the JAX-RS part (e.g. jersey). I
had a look at JSR-311 spec 0.7 but couldn't find a clear separation
between the JAX-RS application and the consumer/user application /
software (the part that provides e.g. a ComponentProvider (that uses
some IoC-container), resource classes etc).
What would you say is the right wording for this?
Cheers,
Martin
>
>
> > 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.
>
--
Martin Grotzke
Dipl.-Inf.
freiheit.com technologies gmbh
Straßenbahnring 22 / 20251 Hamburg, Germany
fon +49 (0)40 / 890584-0
fax +49 (0)40 / 890584-20
HRB Hamburg 70814
eb0e 645c 9730 c8a3 ee2f 1b9a 5de5 21cb c259 fe34
Geschäftsführer: Claudia Dietze, Stefan Richter, Jörg Kirchhof