On Mar 19, 2008, at 5:09 AM, Paul Sandoz wrote:
> 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.
>
Agreed, given this new information I think option (v) is a no-go.
> 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.
>
Seems like (iv) is closest to what the majority of the EG preferred so
unless there's further discussion I think that is the option we should
go for.
Marc.
>
> 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
>
> ---------------------------------------------------------------------
> 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.