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.
> 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 question
----------------\
Paul Sandoz
x38109
+33-4-76188109