Classloader problems

[Ca...@vrtx.com]

Hi all,

[Not sure if this is appropriate for -user or -development, but here 
goes...]

I'm using xmlbeans with sun's JavaSpaces.  With this technology, code 
(including xmlbeans in my case) is run on a remote server.  The relevant 
classes are downloaded from an RMI server, using an RMI classloader.

The first problem I encountered ocurred in places like 
SchemaTypeImpl.getJavaClass(), which, when parsing an XML file, calls 
tries to load a resource (a .xsb file) from my autogenerated jar, in order 
to determine a class name.  The problem is that class loader is unable to 
download a resource from a jar that is retrievable using RMI.  To get 
around this, I added the ugly hack of defining the class loader as a

new URLClassLoader (new URL[] {new URL 
                            ("http://10.13.4.27:8080/problem/myjar.jar")}, 

                    _typeSystem.getClassLoader());

This circumvented that problem, but obviously, hardcoding in the URL of my 
RMI server is a bad idea.  Is there a preferred way I could pass in the 
URL for an RMI class loader to load?

It turned out I had to make similar changes in several other places 
throughout the code, always because of similar issues.  The second, and 
more serious problem I encountered, is that there is a similar issue with 
one of my auto-generated classes, TypeSystemHolder.  This has a line

return 
(org.apache.xmlbeans.SchemaTypeSystem)Class.forName("org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl", 
true, TypeSystemHolder.class.getClassLoader()).getConstructor(new Class[] 
{ Class.class }).newInstance(new Object[] { TypeSystemHolder.class });

which, because its using the TypeSystemHolder class loader) returns a 
class that is not equal to the same class when loaded by a newly created 
RMI Class Loader.  I can't just use the hack I did above, because it would 
mean editing auto-generated code.

I've considered using the TypeSystemHolder.class.getClassLoader() to get 
the actual RMI loader, instead of creating my own, but this would require 
adding the auto-generated code to the class build path for building 
xbean.jar itself, which is both circular and really ugly.

Any suggestions?  Has much thought been given to how xmlbeans will work if 
used with RMI?

Thanks in advance,
Carl