thanks for your info. URLClassLoader can indeed handle http without problems, just add the URL in the getSystemClassLoaderUrls in ClassLoader.java (my previous solution may also work).
The problem came from our solution for bootstrap remote class loading. To make it work we have to perform a test to skip gnu/java/net/loader/Load_* , gnu/java/locale/LocaleInformation_* . Concerning Load_* , we only tested Load_File, but using the jar:http:// URL makes the loader try to load Load_Jar, so we skipped this one as well (replace our strmp by strstr to be sure we handle every case of Load_* and LocaleInformation_*). Thanks 2007/6/2, Martin Schlienger <[EMAIL PROTECTED]>:
No I am currently using full classpath and this class is present. The only think I've done is calling addURL. It doesn't even try to load the class (never call loadClass from ClassLoader, I put some debug output in these methods). What should be the right way to make URLClassLoader use http url? Martin. 2007/6/2, Tom Tromey <[EMAIL PROTECTED]>: > > >>>>> "Martin" == Martin Schlienger <[EMAIL PROTECTED]> writes: > > Martin> Well I am actually patching URLClassLoader. RemoteURLLoader > Martin> seemed to provide some connection to http protocol. When is it > Martin> exactly used? > > The various Loader classes are used to handle particular URL types. > RemoteURLLoader is used for things other than file: and jar:. > > Martin> Caused by: java.lang.NoClassDefFoundError: > gnu/java/net/protocol/http/Headers > > That class is part of Classpath. Did you remove it as part of your > size reduction? All the files in that package are needed for http: to > work. > > Martin> Is this sci-fi to work inside URLClasseLoader to load classes > Martin> from http URL ? > > Nope, it should be pretty easy. Really you shouldn't have to modify > URLClassLoader at all. > > Tom >
