Re: JSR311: Are root resource classes allowed to be singeltons? [Re: JSR311: POLL - Targets for @*Param, @DefaultValue, @Encoded]

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Tue, 11 Mar 2008 16:06:17 -0400

We agreed early on that per-request would be the default lifecycle but
didn't want to limit to that. See e.g.:

I don't think it would be practical to limit lifecycle to per-request,
particularly for those implementations that defer to an IoC framework
for object creation.

Jersey defines a proprietary @Singleton annotation that may be applied
to resource classes.


On Mar 11, 2008, at 3:49 PM, Stephan Koops wrote:

> Hi,
> sorry, that I'm answering again.
> But before deciding this, there must be another decision: Must root
> resource classes be created for every http request ? The current
> spec defines, that resource classes are created for every request.
> In my understanding a root resource class is also a resource class.
> So the singelton argument is not valid, and with this the lifecycle
> argument. If resource classes aren't root resource classes here,
> this should (IMO MUST) be precised in the spec.
> From this following: If root resource classes are allowed to be
> singeltons, the section "Resources", "Resource Classes",
> "Constructors" has no sense in the state as it is now.
> Before deciding on which target to support @*Param (and
> @DefaultValue and @Encoded), it must be decided if root resource
> classes must be created for every request, or if both is allowed.
> Stephan
> Marc Hadley schrieb:
>> There's been a lot of discussion of whether or not to expand the
>> targets (i.e. what Java artifacts you can use the annotation on) of
>> the @*Param annotations (i.e. @PathParam etc al). If we do add
>> targets for these annotations I think we also need to do the same
>> for @DefaultValue and @Encoded. I'm uncomfortable adding targets
>> that are only supported in some implementations so if we do add
>> targets they will be required to be supported on resource classes
>> (not providers) in all implementations.
>> Discussion so far has been between Bill, Stephan and myself, I'd
>> like to hear from others hence this poll. Please choose from the
>> following and reply to the list with your selection. Silence means
>> you don't care what happens - how could that be ;-).
>> Here are the options for target I see:
>> (i) Parameter. The status quo. Works with any lifecycle.
>> (ii) Parameter and field. Spec will warn that use on a field in a
>> singleton resource isn't supported.
>> (iii) Parameter and field. Spec will require use of a proxy for
>> field injection. Pro: singletons can be supported. Con: will affect
>> performance. Con: still won't work for simple types, spec will warn
>> about this.
>> (iv) Parameter, field and method (bean setter). Spec will warn that
>> use on a field in a singleton resource isn't supported and that use
>> on method will require application-managed thread-local handling.
>> Pro: bean setter enable support for singletons. Con: complicated
>> bean setters.
>> (v) Parameter, field and method (bean setter). Spec will require
>> use of a proxy for field and method injection. Same pros and cons
>> as (iii).
>> Vote early, vote once.
>> Marc.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.