As an experiment, I created a directory under WEB-INF called "ext" and dumped a
JAR file in it (commons-cli-1.0.jar). Then I created a servlet that did:
URL jarURL = getServletContext().getResource("/WEB-INF/ext/commons-cli-1.0.jar");
URL[] urls = { jarURL };
ClassLoader ctxClassLoader = Thread.currentThread().getContextClassLoader();
URLClassLoader urlClassLoader = new URLClassLoader(urls, ctxClassLoader);
String className = "org.apache.commons.cli.ParseException";
String classResourceName = className.replace('.', '/') + ".class";
Class cls = urlClassLoader.loadClass(className);
System.out.println("URL of " + cls.getName() + ": " +
cls.getClassLoader().getResource(classResourceName));
On TC 4.1.16, the output was:
URL of org.apache.commons.cli.ParseException:
jar:jndi:/localhost/WEB-INF/ext/commons-cli-1.0.jar!/org/apache/commons/cli/ParseException.class
Which is just the kind of thing you want, yes?
Quoting Ola Berg <[EMAIL PROTECTED]>:
> > I have an analogous case, in which I have a single API for database
> > access, with choice of database (Oracle, MySQL,...) made at run-time.
> > The problem was simply solved using the 'Abstract Factory' pattern. This
> > means that I have two packages (....db.MySql, & ....db.Oracle), which
> > both include an implementation of a DBFactory. I then use ClassForName()
> > to load the appropriate implementation, and then call factory methods to
> > instantiate the appropriate classes.
>
> But I need to bother with class loaders. The classes have the same name but
> different implementations. This resides outside of my control. Solution (in
> the standalone app) is to load the implementations on demand using different
> URLClassLoaders.
>
> /O
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
Kris Schneider <mailto:[EMAIL PROTECTED]>
D.O.Tech <http://www.dotech.com/>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
