classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ServiceFactory


From: Sascha Brawer
Subject: ServiceFactory
Date: Fri, 19 Mar 2004 12:05:55 +0100

Hi all,

there's several places in the Java API where users can write custom plug-
ins, or "service providers". Examples include java.nio.charset,
javax.print, javax.imageio, com.sun.jdi (the client side API for
connecting to remote debugging targets), and some other packages. Plug-
ins are usually deployed as JAR files whose "META-INF/services" directory
contains text files listing the fully qualified names of classes that
implement the respective service.

Attached is an implementation of a new utility class,
gnu.classpath.ServiceFactory. Its lookupProviders methods are intended
for Classpath code that needs to load service providers. I've tried to
explain everything in the Javadoc, so please refer to the code for details. 

I have several questions:

1. It would be great if someone experienced with Java security could
review the implementation.

2. Which namespace? The JDK actually defines a public API for loading
service providers, namely javax.image
io.spi.ServiceRegistry.lookupProviders. Since some people on IRC didn't
like the idea that packages like java.nio.charset would call into
javax.imageio, I've put my implementation into the gnu.classpath
namespace. Personally, I don't really care about the name.

3. The unit tests (see attached ForMauve.tar.gz) run checks on
gnu.classpath.ServiceFactory. This seems a bit unclean, since Mauve was
once meant to be independent of Classpath. A possibility would be to
change the tests so that they check the public API
javax.imageio.spi.ServiceRegistry.lookupProviders. We could easily write
an imageio ServiceRegistry in Classpath that would delegate
lookupProviders to gnu.classpath.ServiceFactory. However, we recently had
agreed to stop committing mostly stubbed implementations. Do people think
this would warrant an exception to the rule?

4. The Mauve tests #5 and #8 fail both on JamVM and on gcj. (Thanks to
Michael Koch for testing on gcj, by the way). Basically, what happens is
something like the following:

  Class c = myClassLoader.loadClass("name");
  harness.check(c.getClassLoader() == myClassLoader);

Can anyone explain why this fails? myClassLoader is an instance of
gnu.testlet.gnu.classpath.ServiceFact
ory.lookupProviders.CustomClassLoader, which doesn't override loadClass.

5. Feel free to tell me if the documentation needs to be improved.

Best regards,

-- Sascha

Sascha Brawer, address@hidden, http://www.dandelis.ch/people/brawer/ 

Attachment: ForClasspath.tar.gz
Description: GNU Zip compressed data

Attachment: ForMauve.tar.gz
Description: GNU Zip compressed data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]