Bill Burke wrote:
> Can somebody explain (iv) again?
>
> Does it mean that field/setter injection is not supported for singletons?
>
For field injection of @*Param would not be supported. Injection of
@Context would be.
> What does "that use on method will require application-managed
> thread-local handling." mean?
>
Meaning that the following setter is reentrant:
@QueryParam("id") void setId(String id) {
// Not thread safe
this.id = id;
}
Paul.
>
> 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
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109