Richard Wallace wrote:
> Richard Wallace wrote:
>>> It would be nice to 'mix-in' Jersey specific constructor parameter
>>> injection with Guice constructor parameter injection. You can get the
>>> Jersey specific per-request parameters using:
>>>
>>> ResourceProviderContext.getParameterValues
>>>
>>> But Marc could not find a way in Spring to do the merging, perhaps in
>>> Guice it is possible?
>>>
>> I agree this would be nice. I think I know a way to do it with Guice,
>> but it's a bit hacky. With Guice you can bind to a given class with a
>> certain annotation either a class that Guice will instantiate, an
>> instance that Guice should use, or a an instance of a Guice Provider.
>> It's this last one that we could use, but the question becomes how
>> does the Guice Provider get the information for the request because
>> this binding happens at startup. The best solution that I've been
>> able to come up with is to stuff the Jersey objects that could be
>> injected into a ThreadLocal that the Guice Provider will use to get
>> the objects and return them to Guice for injection. But I'm not sure
>> about what all the objects are that could be injected or the best way
>> to get access to them. I guess I could just use the
>> ResourceProviderContext.getParameterValues and only stuff those into
>> the ThreadLocal for the Guice Provider to use.
>
> On second thought, this isn't going to be as easy as I had hoped. The
> thing I had overlooked was the overloaded @MatrixParam, @QueryParam,
> @UriParam, and @HeaderParam annotated parameters that are all of type
> String.
Such a parameter can be String, or a class that supports a constructor
with a String parameter or a static method of the signature "T
valueOf(String)". Plus such information can only be obtained in a
per-request scope from the HTTP request.
> Guice has the @Named annotation which does something similar
> but allows for any type.
> The real problem, though, is that whatever IoC container would have to
> know something about all the possible parameters to be injected, which
> just isn't really possible since the @UriParam and other params are
> really dependent on the class being injected. I can't think of a way to
> overcome this and actually my preferred modus operandi would probably be
> to have my Resource be a singleton and have parameters passed into the
> methods annotated with HttpMethod.
>
OK.
Perhaps it is also worth logging a bug with Guice?
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109