Richard Wallace wrote:
>
> The most common scenario is something like below:
>
> @Path("/items/{item-name}")
> public class ItemResource {
>
> private final ItemRepository repository;
>
> @Inject
> public ItemResource(ItemRepository repository) {
> this.repository = repository;
> }
>
> ...
> }
>
> So when Guice gets a request to create an instance of ItemResource it
> will find the constructor annotated with the @Inject annotation and use
> that passing it the required dependencies.
I see, that was very helpful. So Guice is in control.
> In a case like the above, it
> would be nice to be able to add the UriInfo object and probably the
> item-name parameter since that is going to be something needed by all
> the methods. Up until now I've simply been having that stuff passed to
> the methods as parameters which is ok, but doesn't seem quite as nice.
>
> The way I would go about binding those parameters in Guice is along the
> lines of something like this:
>
> public class JerseyModule extends AbstractModule {
>
> public void configure() {
> bind(UriInfo.class).annotatedWith(Context.class).toProvider(new
> Provider() {
> // lookup thread local context or the thread local UriInfo
> and return it
> });
> }
> }
>
> That's just for the UriInfo type. I'd also need to create bindings for
> the other possible values as well. Since the ThreadLocalHttpContext is
> something internal to the Jersey implementation it seems it would be
> better if I could have some better way of looking these things up, but
> I'd settle for getting that much at this point.
>
Can the JerseyModule have access to the WebApplication? if so i can add
a method WebApplication.getThreadLocalHttpContext() so you can proceed
while we can try and take more time to solve this a better. OK?
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...).
>>> 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.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109