I had a similar problem, which I posted last week. You should find it
searching the Subject field for pluggable protocols in web apps if you
kee pold messages. What I found out so far is this:
- Defining the protocol handler doesn't do any harm. The URL class
searches through the system property java.protocol.handler.pkgs if it
doesn't get a protocol handler from the factory.
- The problem is that URL tries to load the class with
Class.forName(String) method (Check out the method static
URLStreamHandler getURLStreamHandler(String protocol)).
- Class.forName(String) calls the method
ClassLoader.getCallerClassLoader(), which returns null. I think this
means it uses the remodial classloader
- The premodial classloader cannot find the class becaus it is not in
the bootstrap classpath.
- Subsequently the system class loader is asked to load the class. This
classloader cannot find the class either, because the classes in the web
application are not in the classpath when tomcat was started.
- To solve the problem temporarily is put the protocol handler in the
class path.
- The disadvantage with this method is you need to distribute the
protocol handler separately. And if you need classes from the web
application, you need to add the webapp class repository the protocol
handler's list of repositories.
Martin Goldhahn
-Original Message-
From: Peter Crowther [mailto:[EMAIL PROTECTED]
Sent: Friday, February 11, 2005 2:59 PM
To: Tomcat Users List
Subject: URL protocol handler issues
Environment: Tomcat 5.0.28, built from source.
I'm trying to persuade Tomcat to allow me to use a custom URL
scheme ('bod3vfs'), both in webapps and in some of the
behind-the-scenes setup
- for example, I have a custom HostConfig that examines a
virtual file system. I've tried the following approaches to
getting this integrated; none of them appear to work. Ideas welcome!
1) Create the handler in org.bodington.core.protocol.bod3vfs.Handler.
Package that into bodington3.jar; place in server/lib. Call
a static routine just after startup to amend
java.protocol.handler.pkgs to include
org.bodington.core.protocol. Result: MalformedURLException
when asking for bod3vfs:*.
2) As per 1, but add
-Djava.protocol.handler.pkgs=org.bodington.core.protocol.
Result as 1.
3) Amend DirContextURLStreamHandlerFactory to include the following:
public URLStreamHandler createURLStreamHandler(String protocol) {
if (protocol.equals(jndi)) {
return new DirContextURLStreamHandler();
} else if (protocol.equals(bod3vfs)) {
return new org.bodington.core.protocol.bod3vfs.Handler();
} else {
return null;
}
}
... and ensure that the factory replaces the standard factory
before it's required, in my custom HostConfig (which is
successfully loaded from bodington3.jar). Result:
java.lang.reflect.InvocationTargetException caused by
java.lang.NoClassDefFoundError:
org/bodington/core/protocol/bod3vfs/Handler at the point that
the runtime attempts to load
DirContextURLStreamHandlerFactory. Note that the compilation
was successful, and that the invoking class has been loaded
successfully from the same jar that contains the handler. If
I replace the return statement with 'return null',
DirContextURLStreamHandlerFactory loads and runs successfully.
4) Copy the Handler class into catalina.jar and repeat 3.
Same result.
Remy, the original code for DirContextURLStreamHandlerFactory
is yours, I think. Any particular reason you replaced the
factory rather than setting the packages?
- Peter
--
Peter Crowther, Director, Melandra Limited John Dalton House,
121 Deansgate, Manchester M3 2AB
t: +44 (0)161 828 8736 f: +44 (0)161 832 5683
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
