On Nov 6, 2009, at 5:02 PM, Joe Bradley wrote:
> Thanks Paul. I tried this but it doesn't seem to be working and it's
> not obvious to me why not. The Jersey runtime discovers the
> RequestAttributeInjector as a provider and constructs it, but the
> getInjectable method is never called. I'm using the RequestAttribute
> annotation in my resource class exactly has you have it below.
>
> Any ideas?
>
Not sure, i wrote the code directly in the email without testing, let
me try a simple example.
Paul.
> Joe
>
> Paul Sandoz wrote:
>>
>> Hi,
>>
>> Request-scoped properties are available on HttpContext. Such
>> properties are distinct from servlet request attributes and there
>> no attempt to keep the two in sync.
>>
>> Here is one idea:
>>
>> @Target({FIELD, PARAMETER, METHOD})
>> @Retention(RUNTIME)
>> @Documented
>> public @interface RequestAttribute {
>> String name();
>> }
>>
>>
>> @Provider
>> public class RequestAttributeInjector implements
>> InjectableProvider<RequestAttribute, Type> {
>> private final HttpContext c;
>>
>> private final HttpServletRequest r;
>>
>> public UserInjector(@Context HttpContext c, @Context
>> HttpServletRequest r) {
>> this.c = c;
>> this.r = r;
>> }
>>
>> public ComponentScope getScope() {
>> return ComponentScope.PerRequest;
>> }
>>
>> public Injectable getInjectable(ComponentContext ic,
>> RequestAttribute a, final Type t) {
>> final String name = a.name();
>>
>> return new Injectable() {
>> public Object getValue() {
>> Object o = c.getProperties().get(name);
>> if (o == null) {
>> o = r.getAttribute(name);
>> }
>> if (o == null) {
>> // Throw exception or return null?
>> }
>>
>> // TODO verify that o.getClass() is compatible with
>> Type t
>> return o;
>> }
>> }
>> }
>> }
>>
>>
>> @Path("foo")
>> public class MyResource {
>> private final MyValue v;
>>
>> public MyResource(@RequestAttribute("foo") MyValue v) {
>> this.v = v;
>> }
>> }
>>
>> Paul.
>>
>> On Nov 6, 2009, at 4:20 AM, Moises Lejter wrote:
>>
>>> I'm thinking you could write an InjectableProvider for
>>> MyCustomType, which has the HttpServletRequest injected, and which
>>> could inject your MyCustomType into any other of your classes via
>>> @Context ...
>>>
>>> Moises
>>>
>>> On Thu, Nov 5, 2009 at 6:48 PM, Joe Bradley <gjoelbradley_at_netscape.net
>>> > wrote:
>>> Moises,
>>>
>>> But that would require us to manually extract the request
>>> attribute in the resource method per below. We will need this
>>> attribute in every resource method in our app, so I'm trying to
>>> save from having to do that repetively.
>>>
>>> @Path("/foo")
>>> public class MyResource {
>>>
>>> @Context
>>> HttpServletRequest request;
>>>
>>> @GET
>>> @Path("/bar")
>>> public Bar getBar() {
>>>
>>> MyCustomType custom =
>>> request.getAttribute("MyCustomAttribute");
>>>
>>> return ...
>>> }
>>> }
>>>
>>> What we really want is:
>>>
>>> @Path("/foo")
>>> public class MyResource {
>>>
>>> @Context
>>> MyCustomType custom;
>>>
>>> @GET
>>> @Path("/bar")
>>> public Bar getBar() {
>>>
>>> // Use custom here...
>>>
>>> return ...
>>> }
>>> }
>>>
>>> Joe
>>>> Subject: Re: [Jersey] Why doesn't HttpRequestContext expose
>>>> request attributes?
>>>> From: Moises Lejter <moilejter_at_gmail.com>
>>>> Date: Thu, 5 Nov 2009 11:59:09 -0600
>>>> To: users_at_jersey.dev.java.net
>>>> To: users_at_jersey.dev.java.net
>>>>
>>>> Hi!
>>>>
>>>> I thought that HttpServletRequest was injectable via @Context ?
>>>> That would give you access to the request parameters ...
>>>>
>>>> Moises
>>>>
>>>> On Thu, Nov 5, 2009 at 11:04 AM, Joe Bradley
>>>> <joe.bradley_at_sun.com> wrote:
>>>> I want to inject a custom object type into resource classes using
>>>> @Context. The custom object would be instantiated in an servlet
>>>> filter upstream of Jersey and placed in a request attribute.
>>>>
>>>> I've seen an example of writing a Provider to extract the Locale
>>>> from the HttpRequestContext and was trying to do something
>>>> similar to extract our custom object. However since
>>>> HttpRequestContext doesn't expose the request attributes I don't
>>>> see a way to make this work.
>>>>
>>>> Are there any alternative approaches?
>>>>
>>>> Joe
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>>
>>>
>>>
>>
>