Can somebody explain (iv) again?
Does it mean that field/setter injection is not supported for singletons?
What does "that use on method will require application-managed
thread-local handling." mean?
Ryan McDonough wrote:
> I agree with Marc and Paul that (iv) is a better option given this new info.
>
> Ryan-
>
> On 3/19/08, *Marc Hadley* <Marc.Hadley_at_sun.com
> <mailto:Marc.Hadley_at_sun.com>> wrote:
>
> 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 <http://sun.com>>
> >> CTO Office, Sun Microsystems.
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
> >> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> <mailto: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
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
> > For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> <mailto:dev-help_at_jsr311.dev.java.net>
> >
>
> ---
> Marc Hadley <marc.hadley at sun.com <http://sun.com>>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> <mailto:dev-help_at_jsr311.dev.java.net>
>
>
>
>
> --
> Ryan J. McDonough
> http://www.damnhandy.com
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com