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.
>