Alright, well I'm a bit stuck now. Apparently the annotation used in
bind(UriInfo.class).annotatedWith(Context.class).toProvider(...) has to
be annotated with the BindingAnnotation. I'll have to post to the guice
list and see why this limitation exists and if I can work around it.
Otherwise I'll just have to come up with my own annotations or rely on
the parameters passed to the method (what I'm doing now). Neither is
as appealing as Guice being able to inject the things I want, but if
that's what I gotta do that's what I gotta do.
Rich
Richard Wallace wrote:
> Paul Sandoz wrote:
>> Richard Wallace wrote:
>>> I don't think the JerseyModule can have access to the WebApplication
>>> because it seems we run into a chicken-and-egg, circular dependency
>>> thing... I need to create the injector before Jersey starts up but I
>>> need to have Jersey start up before I can create the injector.
>>> Alternatively, in looking at the ServletContainer class the
>>> WebApplication create() method is protected so I could override that
>>> have the Guice injector responsible for instantiating a
>>> WebApplication object. I like that because there are all sorts of
>>> ways I can do things at that point, like having an interceptor for
>>> handleRequest() or whatever else I might need down the road. The
>>> other thing that allows me to do is to have the WebApplication
>>> injected into the Providers that will resolve the Jersey parameters.
>>
>> I see, so you would create a WebApplication wrapper around the one
>> returned from WebApplicationFactory.createWebApplication() ? There is
>> a lot of implemented functionality in the one returned by the factory
>> that is core to the Jersey runtime.
>>
>
> Yes, sorry. Forgot to mention I would bind the WebApplication
> interface to the WebApplicationImpl class so I would be using all the
> same stuff that Guice uses, just bypassing the WebApplicationFactory
> and the Service finding stuff.
>
>>
>>> So I'll have easy access to the getThreadLocalHttpContext() method
>>> or whatever other API you might come up with for exposing these
>>> values.
>>>
>>
>> Some additional stuff on WebApplication would make sense i think (see
>> below).
>>
>> From the perspective of ComponentProvider it looks like we could make
>> some improvements, or relax the requirements, for example: Jersey may
>> have a preferred constructor for a class but the underlying
>> ComponentProvider is free to override that selection if it supports
>> getting an instance of that class.
>>
>>
>>>>
>>>> AFAICT there does not seem a way in Guice to merge constructor
>>>> parameters e.g. "create an instance of this class and oh by the way
>>>> here of the parameters instances that i know about".
>>>>
>>>> Jersey injects 'singleton' and 'per-request' instance data for
>>>> constructor parameters. For each parameter Jersey creates an
>>>> 'extractor' instances by analyzing the parameters using Java
>>>> reflection (it would be nice to cache such 'extractor' classes
>>>> rather than having to do this work every time a request is made).
>>>> It seems that this is the key piece of infrastructure that would be
>>>> useful to expose e.g. for this parameter type get me the extractor
>>>> instance.
>>>>
>>>> This is the interface:
>>>>
>>>> public interface ParameterExtractor {
>>>> Object extract(HttpRequestContext request);
>>>> }
>>>>
>>>> You can see that the:
>>>>
>>>> com.sun.ws.rest.impl.resource.PerRequestProvider
>>>>
>>>> gets an array ParameterExtractor instances. And then when an
>>>> instance is required loops through the extractors calling extract
>>>> with the HttpRequestContext (now a real performance boost would be
>>>> to dynamically create byte code to do the extraction, but that is
>>>> for another day...).
>>>>
>>>
>>> Ah ok. Now I see how Jersey is determining what to inject. So,
>>> actually, if I do create an interceptor for the
>>> WebApplication.handleRequest() method I can set my own ThreadLocal
>>> with the request and response and then for my Guice Providers I can
>>> use the appropriate extractors to get the values out of the request,
>>> just as Jersey does internally. I'll have to play with that a bit
>>> but I think that should work beautifully.
>>>
>>
>> I at a minimum it would seem something like this is required:
>>
>> ParameterExtractor WebApplication.getParameterExtractor(
>> Annotation[] a,
>> Class<?> c,
>> Type t);
>>
>> Note that current parameter extractor logic is abstracted from Java
>> reflection (we thought there might be ways other than annotations for
>> declaration) so this method requires a little bit of extra work to
>> integration into the current design.
>>
>>>>
>>>>>>> I've noticed in going through the code that there are many other
>>>>>>> places where raw types are used in Jersey instead of generified
>>>>>>> types.
>>>>>>
>>>>>> Could you point to other areas?
>>>>>>
>>>>>
>>>>> Well, there are quite a few of them, so I can't list them all out.
>>>>> ;) Eclipse lists 255 over the entire project, with 39 in api, 198
>>>>> in impl and 18 in spi. The ones that would probably most effect
>>>>> people like me are the ones in spi, but the ones in api are
>>>>> arguably just as important.
>>>>>
>>>>
>>>> Right, i would like to tidy up the spi/api.
>>>>
>>>> Is it possible extract what Eclipse lists out as a text file?
>>>> (NetBeans is lacking this feature, or i am not aware of such a
>>>> feature).
>>>>
>>>> Paul.
>>>>
>>>
>>> What's really weird is that I tried modifying the project.properties
>>> to tell it to show the warnings, but it already has -Xlint:unchecked
>>> set for javac.compilerargs but it still isn't showing the warnings.
>>> If I change it to just -Xlint it shows deprecations and unused
>>> variables, but not the raw type warnings like it should. Really
>>> weird. Anyways, attached is the list of warnings Eclipse gives me.
>>> They're not all type warnings, but the majority are.
>>>
>>
>> Thanks!
>> Paul.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>