Hello Scott,
> 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.
Yes: JBoss should directly read from the local filesystem and not go through
the web server.
No : if the URL is set to a local file, the web server thing is completely
useless (in the current state). Who/what will use it?
> 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.
In fact, with Vladimir Blagojevic, had two "not-so-nice" solutions:
1) As a URLClassLoader is built using an array of URLs, simply add a
http:// URL after the file:// URL in the class loader. This way, the server
will load from the file and the client will load from the web (after having
failed from loading a first time from the file). This has nevertheless a big
problem: applets will stil fail as the first try (FS) will raise a security
exception.
2) Extending URLClassloader in this way (~) :
lass URLLocalClassLoader extends URLClassLoader
{
private URL _foreignName = null;
// new constructor added
//
public URLLocalClassLoader (URL foreignName, URL[] localNames)
{
super (localNames);
this._foreignName = foreignName;
}
// override getUrl
//
public URL[] getURLs()
{
URL[] answer = {this._foreignName};
return answer;
}
}
This way, everything is nice on the server and the client (applet or not).
BUT, we didn't know the "border effects" of manipulating the getURLs this
way.
Nevertheless, whatever solution is choosen, dynamic classloading can only be
better than now! ;)
Just for completeness, we have a third option, by solving the problem on on
the client side:
Properties env = new Properties();
env.setProperty("java.naming.factory.initial",
"org.jnp.interfaces.NamingContextFactory");
env.setProperty("java.naming.provider.url", "localhost:1099");
env.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming");
System.setProperty ("java.rmi.server.codebase",
"http://DuppleBupple:8080";);
System.setProperty ("java.rmi.server.useCodeBaseOnly", "true");
System.setProperty ("java.security.policy", "c:/policy.txt");
System.setSecurityManager (new java.lang.SecurityManager());
try
{
// Get a naming context
InitialContext jndiContext = new InitialContext(env);
System.out.println("Got context");
...
But :
- this is not transparent at all
- this will still not work with applet as writing the java.rmi...
properties is forbidden.
Opinions?
Cheers,
Sacha
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
