On Jun 9, 2010, at 9:16 AM, Lucas Ventura wrote:
> Paul Sandoz wrote:
> On May 28, 2010, at 11:21 AM, Lucas Ventura wrote: I would be
> surprised if ClassLoader.getResources ceased to function correctly
> to load resources (that method is used to load the META-INF/
> services files). But a quick search does indicate others are having
> similar issues with packaging and META-INF/services.
> The problem after inspecting a little bit, is that the ClassLoader
> created by Google neither can't find services files, nor the class
> implementations.
Drat... Google forked Java platform :-)
> Paul Sandoz wrote:
> There might be a way. It is possible to override the META-INF/
> services lookup by using the following method: https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/spi/service/ServiceFinder.html
> #setIteratorProvider
> %28com.sun.jersey.spi.service.ServiceFinder.ServiceIteratorProvider
> %29 So you could provide your own implementation. Paul.
> So I've provided a hardcoded implementation with the names of the
> classes indicateds in the META-INF/services files. The question is:
> when I should do this call to serIteratorProvider()? Because if I do
> before the Client creation it is looking for service jersey-client-
> components.
Yes, that is expected. If a file META-INF/services/jersey-client-
components is present it will contain one or more class names. You can
just ignore this service name and return an empty iterator.
I think the right general solution is to support a module concept a
bit like Google Guice and remove as much of the META-INF/services
stuff as possible (perhaps one file to declare a module for dynamic
purposes). They it should be possible for developers to compose public
modules that declare components.
Paul.
> If I do after, it works, but... will be called again with a that
> kind of serviceName? Thanks a lot :)
> View this message in context: Re: java.lang.NullPointerException on
> Android
> Sent from the Jersey mailing list archive at Nabble.com.