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.