Re: Help with java.rmi.server.codebase
Niclas Hedhman <[email protected]> Wed, 27 Dec 2006 10:30:17 +0800
| Newsgroups | gmane.comp.java.sun.rmi |
|---|---|
| Message-ID | <[email protected]> |
On Wednesday 27 December 2006 01:07, Vanfleet, David wrote:
> Niclas, I'm not sure I understand what you're saying about the "client
> Jar"?
In order for any remote calls to be made, you are expected to "use" a remote
object by accessing it, typically via a lookup on the Registry;
DTOServiceInterface service = (DTOServiceInterface) registry.lookup("abc");
> I'm trying to get the RMI service to run in the server registry
> and to download needed classes from a remote http server. This remote
> service has no dependencies on the client that will be accessing this
> service.
You are not expected to "run" anything on the Registry, only register the
presence of a remote object (aka service) under a name. I.e. You instantiate
the Remote object (your implementation of the DTOServiceInterface) and call;
DTOServiceInterface instance = new DTOServiceInterfaceImpl();
// possibly doing export of the object outside the object itself;
UnicastRemoteObject.exportObject( instance );
registry.bind( "abc", instance );
Of course you need all the access to the classes for this to work. I think
most people prepare two separate jars for RMI applications;
1. "-full" or "-server" which contains all classes that are needed at the
server side.
2. "-client", "-download" or "-dl" which contains the classes that are needed
by the client. These are effectively; The Remote subinterface, all classes
used in that interface as return types, method arguments and exceptions.
Also, often people prepare convenience classes, such as JavaBeans for some
of the value types used.
The Registry must be on the same host as the remote object being registered
(look at Jini for other solution, if that is inconvenient), and can either be
started from commandline "rmiregistry" or by starting it from within your
application by LocateRegistry.createRegistry(...);
> So, you're saying that because this class is being referenced from
> within this remote interface it can't be downloaded dynamically from
> java.rmi.server.codebase? It seems that this limitation causes this
> functionality to loose some of it's usefulness. What am I not
> understanding here?
Not sure what you are missing.
1. The system property java.rmi.server.codebase is not the codebase to be used
by the RMI "server side" to load any classes. It is ONLY used to annotate the
MarshalledObject (the data stream that is sent between the hosts) with
information of where the classes can be found.
2. IF the classloader of the classes needed, use http:// or ftp:// URLs, then
the java.rmi.server.codebase property is not needed/used, and instead the
MarshalledObject is annotated with those URLs.
3. That means, if you ONLY use http:// URLs for your URLClassloader(s) on both
ends, you don't need to bother about the java.rmi.server.codebase at all.
IIRC, the "java -cp" doesn't allow http URLs and you need to have a little bit
bootstrapping of your own URLClassloader with the proper codebase.
Hope this helps.
Cheers
Niclas
===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS". For general help, send email to
[email protected] and include in the body of the message "help".
For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html
To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html