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 <m.schlienger@xxxxxxxxx>:
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 <tromey@xxxxxxxxxx>:>>>>> "Martin" == Martin Schlienger <m.schlienger@xxxxxxxxx> 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
