On Feb 11, 2009, at 2:39 PM, Chris Winters wrote:
> On Wed, Feb 11, 2009 at 4:35 AM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>> On Feb 10, 2009, at 11:49 PM, Chris Winters wrote:
>>> It looks like I can fart around with providing the correct
>>> javax.ws.rs.ext.RuntimeDelegate implementation with a properties
>>> file
>>> somewhere or other ($java.home/lib -- really? ugh), so I'll try
>>> that.
>>
>> Yes, ugh, not ideal. Another approach might be to register the Jersey
>> RuntimeDelegateImpl in that listener explicitly:
>>
>> RuntimeDelegate.setInstance(new
>> com.sun.jersey.server.impl.provider.RuntimeDelegateImpl());
>>
>> You could do this using your own servlet context listener. Or
>> override the:
>>
>> com.sun.jersey.spi.container.servlet.ServlerContainer
>>
>> and in the constructor set the runtime delegate instance.
>>
>> Would it be possible to try the above? if it works we could support a
>> special feature, as an init-param, to explicitly set the runtime
>> delegate.
>
> Your suggestion worked just fine, and I like it much better than
> creating files in ${java.home}/lib.
>
> FWIW, I was already implementing my own version of SpringServlet
> because our ApplicationContext, while available in the normal location
> in ServletContext, is hierarchical -- all the beans are in the parent,
> so none of the root resources were found via the normal means. (I plan
> on shortly filing an issue about this with an easy fix.)
>
Great! If you have time it would be most helpful to supply a test
case, or a simple example such that i can develop one to ensure that
we do not regress.
Paul.