(i)
On Mar 11, 2008, at 6:36 PM, 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
>
>