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.