On Mar 20, 2008, at 6:55 AM, Bill Burke wrote:
> Can somebody explain (iv) again?
>
> Does it mean that field/setter injection is not supported for
> singletons?
>
It means that the runtime won't differentiate between per-request and
other lifecycle resource classes (since it may not be able to tell the
difference) so we'll warn developers that for other lifecycles they
should use resource method parameters rather than instance fields or
bean properties.
> What does "that use on method will require application-managed
> thread-local handling." mean?
>
Ignore that comment - not fully thought through and wouldn't help.
Marc.
>
> 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
>
> ---------------------------------------------------------------------
> 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.