On Nov 11, 2012, at 6:00 PM, Marek Potociar <marek.potociar_at_oracle.com> wrote:
>
> On Nov 8, 2012, at 3:14 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
>>
>> On Nov 8, 2012, at 2:52 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>> I don't know if the spec explicity supports this, but our impmlementation does.
>>
>> Yes, it actually does I think.
>>
>> I found a thread where I asked the same question 3 years ago (yeah . ... shameful indeed :-( ) and Paul Sandoz explained to me that it is designed to work that way; that you can inject per-request information (UriInfo, HttpHeaders etc.) using @Context and that you will get a thread local.
>>
>> However ..... in practice, it does not work. Not even in an MBW.
>>
>> At least not with GF 4 b61.
>>
>> @Marek - can you clarify whether this is a bug.
>
> Well from your point of view it is a bug. From my point of view it is a feature we have not implemented yet (at least it is still in our task list). :)
>
> IOW, no need to file a bug for that.
Btw. as a workaround, you may inject a JSR-330 provider instead in Jersey 2.0, e.g.:
@Inject Provider<UriInfo> uriInfoProvider;
Marek
>
> Marek
>
>>
>>
>>
>> Jan
>>
>>
>>
>> Example:
>>
>> - I am not even accessing the injected ui.
>> - Exception: java.lang.IllegalStateException: Not inside a request scope.
>>
>>
>> @Provider
>> @Produces("application/customer")
>> public class CustomerMessageBodyWriter implements MessageBodyWriter<Customer> {
>>
>> private static Logger log = Logger.getLogger(CustomerMessageBodyWriter.class.getName());
>>
>> //_at_Context
>> HttpHeaders h = null;
>>
>> @Context UriInfo ui;
>>
>>
>> ...
>> }
>>
>>
>>>
>>> On 11/8/2012 2:30 AM, Jan Algermissen wrote:
>>>>
>>>> On Nov 8, 2012, at 3:52 AM, Bill Burke <bburke_at_redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 11/7/2012 6:45 PM, Jan Algermissen wrote:
>>>>>>
>>>>>> On Nov 8, 2012, at 12:39 AM, Bill Burke <bburke_at_redhat.com> wrote:
>>>>>>
>>>>>>> Or an injection of ContainerRequestContext?
>>>>>>>
>>>>>>> @Context
>>>>>>> ContainerRequestContext rctx;
>>>>>>
>>>>>> Yes, that would be even better - but wouldn't that have to be an instance local to aroundWriteTo?
>>>>>>
>>>>>
>>>>> thread local proxies for these types of field injections.
>>>>>
>>>>
>>>> See... thread local has been on my dive-into list for a while. Thanks.
>>>>
>>>> So, I would just do this, right? (IOW, nothing new needed to support my use case)
>>>>
>>>> @Provider
>>>> class TestInterceptor implements WriterInterceptor {
>>>>
>>>> @Context
>>>> HttpHeaders headers;
>>>>
>>>> @Override
>>>> public void aroundWriteTo(WriterInterceptorContext wCtx)
>>>> throws IOException, WebApplicationException {
>>>>
>>>> String h = headers.getHeaderString("Accept-Encoding");
>>>> if(if h !=null && h.contains("gzip") ) {
>>>> // hook gzipper into the ostream
>>>> }
>>>> }
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>
>