> Note that you do not have to use field injection, you can declare
"@Context HttpContext hc" as a constructor parameter of
> the injectable provider.
Indeed, sorry I missed this point in your original reply. (Guess I
really should learn to read more carefully)
I have raised this feature request, Issue #260.
Thanks for your help,
Tim
> Paul Sandoz wrote:
>
> Hi Tim,
>
> Note that you do not have to use field injection, you can declare
"@Context HttpContext hc" as a constructor parameter of
> the injectable provider.
>
> Could you log an issue requesting this feature?
>
> Essentially AbstractHttpContextInjectable is an optimization so a
thread local proxy does not have to be utilized and
> instead the direct instance of HttpContext can be utilized (if present
when injection occurs, otherwise it will be null).
>
> Currently as implemented AbstractHttpContextInjectable need to be
slightly modified to ensure it works correctly for the
> client side invocations for which the client knows nothing of
AbstractHttpContextInjectable i.e. the getValue() needs to be:
>
> public T getValue() {
> return getValue(null);
> }
>
> Paul.
>
>
> On Apr 6, 2009, at 1:52 PM, Tim Edwards wrote:
>
>>
>> Thanks for the reply.
>>
>> Do you feel there is any scope to pull a HttpContextInjectable
>> interface into the spi? The internals already treat using HttpContext
>> in an Injectable as a special case and I was thinking it might be of
>> benefit to users for a couple of reasons:
>>
>> 1) When writing my own Injectables,Providers,etc... I found looking
at
>> the Jersey source an invaluable way of discovering how the various
>> classes should be written. Now there is a case that the Jersey
>> implementations work in a way not available to user defined
>> implementations, which is slightly confusing (hence my original
>> message)
>> as you would expect the internals to be following a 'best practice'
>> way
>> of using the framework.
>>
>> 2) It gives implementers the choice in how to actually implement
their
>> classes. Personally I have avoided using injection into fields,
mainly
>> due to the fact I don't feel the code is as clear when this happens,
>> you are required to understand from where & when the field is
>> injected, without field injection I feel the code is more
>> understandable without requiring to know it's context (although I
>> appreciate this is simply my opinion). This approach has not been an
>> issue as Jersey provides the flexibility to do this, however in this
>> case I would now be forced to use field injection.
>>
>> (Obviously, if there is an intention to convert the Injectables
within
>> the implementation over to the approach below, then this question is
>> probably somewhat irrelevant)
>>
>> Thanks,
>> Tim
>>
>>
>> Paul Sandoz wrote:
>>>
>>>
>>> On Apr 2, 2009, at 5:27 PM, Tim Edwards wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> I started writing an application using Jersey 1.0.0, where I
created
>> a
>>>> custom Injectable which used the HttpContext passed into the
>>>> getValue
>>
>>>> method to obtain the injected value and everything worked as
>> expected.
>>>> Recently I have upgraded to Jersey 1.0.2 and have found that the
>>>> Injectable interface has changed so the HttpContext is no longer
>>>> passed into the getValue method.
>>>>
>>>
>>> You can use:
>>>
>>> @Context HttpContext context
>>>
>>> on a field or a constructor parameter of your injectable provider.
>>> Then pass the reference to the returned Injectable or use an inner
>> class, anonymous or otherwise. For example:
>>>
>>> @Provider
>>> public class MyInjectableProvider implements
>>> InjectableProvider<Context, Type> {
>>>
>>> @Context HttpContext context
>>>
>>> public ComponentScope getScope() {
>>> ...
>>> }
>>>
>>> public Injectable getInjectable(ComponentContext cc, Context ejb,
>> Type t) {
>>> ...
>>> }
>>> }
>>>
>>> Apologies for the change, it was necessary to modify the interfaces
>>> to
>> improve integration with DI technologies like Spring.
>>>
>>> If you need help adapting your injectable classes send me an example
>> and i can tell you how it should be for 1.0.2.
>>>
>>> Hope this helps,
>>> Paul.
>>>
>>>> Unless I'm missing something, the only way I can see of achieving
>>>> the
>>
>>>> same behaviour is to extend the Jersey implementation class
>>>> AbstractHttpContextInjectable. This doesn't seem right, before I
was
>>>> simply implementing part of the spi and now it seems I need to have
>>>> a
>>
>>>> dependency on an implementation class?
>>>>
>>>> Am I just missing something? Is there still a way to give an
>>>> Injectable access to the current request without the implementation
>>>> dependency?
>>>>
>>>> Thanks,
>>>> Tim
>>
If you are not the intended recipient, employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination or copying of this communication and its attachments is strictly prohibited.
If you have received this communication and its attachments in error, please return the original message and attachments to the sender using the reply facility on e-mail.
Internet communications are not secure and therefore Cambridge Assessment (the brand name for the University of Cambridge Local Examinations Syndicate, the constituent elements of which are CIE, ESOL and OCR [Oxford Cambridge and RSA Examinations is a Company Limited by Guarantee Registered in England. Registered office: 1 Hills Road, Cambridge CB1 2EU. Company number: 3484466]) does not accept legal responsibility for the contents of this message.
Any views or opinions presented are solely those of the author and do not necessarily represent those of Cambridge Assessment unless otherwise specifically stated.
The information contained in this email may be subject to public disclosure under the Freedom of Information Act 2000. Unless the information is legally exempt from disclosure, the confidentiality of this email and your reply cannot be guaranteed.