I was away last week... slowly consuming the *many many* emails and
interesting discussions (especially about the Erlang Web server and DDOS
attacks). So please excuse me for chiming in late on this issue.
I would prefer option (i).
Option (v) seems a no go to me since AFAICT it is not possible to
cleanly and directly proxy non-interface based stuff, thus String is not
possible since it is final, makes it hard to support things extending
Number (Integer, BigDecimal etc), and there is no easy solution for
user-defined classes to process parameters. Hence one would have to
explicitly declare:
@QueryParam("abc") ThreadLocal<String> abc;
which sucks IMO.
If we really have to allow @*Param on fields and methods then option
(iv) seems better. It introduces an additional dependency on life-cycle.
In effect it is not just a Singleton resource, but anything other than a
per-request resource where an instance of the resource class is retained
beyond the scope of a request. (There is an existing dependency on
constructors).
I would be inclined to say field and method (bean setter) are only
supported for per-request resources. Thus if a developer chooses a
non-per-request resource there are less ways for bullets to hit feet.
Paul.
Marc Hadley wrote:
> 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.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109