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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>