We agreed early on that per-request would be the default lifecycle but
didn't want to limit to that. See e.g.:
https://jsr311.dev.java.net/servlets/ReadMsg?list=dev&msgNo=538
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.
Marc.
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: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.