I've looked into this bug using a simple RMI client/server testcase that
simulates the behavior in JBoss in that the remote objects it exports
are loaded by an application class loader. The fact that the annotated
codebase of the class is a file url on the server is due to the fact that
this is the url of the URLClassLoader that loaded the ear, jar or war,
but this is the correct class loader. I don't believe we should not have to
load classes from a web server(even if it is embeded) just to set the
the class annotated codebase to the web service url.
The reason for the current behavior is that the java.rmi.server.codebase
property which is set by the WebService(althougth its set too late) is only
used for classes loaded from the system class loader or a class loader that
has been explicitly registered with the internal sun.rmi.server.LoaderHandler
class via the registerCodebaseLoader(ClassLoader) method.
This effectively means that classes that are to be downloaded to clients must
be on system classpath. The only solution short of resorting to use of the
internal sun.rmi.server.LoaderHandler.registerCodebaseLoader(ClassLoader) method
is to write a URLClassLoader that can handle funky urls of the form
http://server:port/path_to_local_jar so that the classes appear to be coming from
the embeded WebServer.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
