URLyBird - RMI dynamic class loading

[Eric Ellis]

Quick question: I just finished the bare bones implementation of my RMI server. I'm new to RMI and am a little worried about the "Restrictions on RMI" section of the specs. I've read several chapters and an entire book on the subject but I'd hate to get this one wrong. Mainly I'm asking because so many other discussions on the subject have suggested "placing the stub in the client directory."

My implementation works as follows:

Server loader creates a registry
Server loader creates the serviceImpl
Server loader registers serviceImpl in the registry

Remote Data Driver (Client) locates the registry
Remote Data Driver (Client) calls registry.lookup()


The client doesn't know anything about the stub. I would assume that this means it's being dynamically loaded. I have no import statements linking the client to the server (except the explicit import of the service interface).

I tried adding the stub source code to my client directory with no visible signs of life. How do I know if it's being used? Any RMI expert could probably answer yes or no. Yes your current implementation is dynamically loading the class or no your fine.

Here is what the spec says:

Restrictions on RMI
To avoid unnecessary complexity in the marking environment certain restrictions are placed on solutions that use RMI. Specifically:
# You must not require the use of an HTTP server.
# You must not require the installation of a security manager.
# You must provide all classes pre-installed so that no dynamic class downloading occurs.
# You must use RMI over JRMP (do not use IIOP)

Thanks in advance to anyone who helps me out

[Eric Ellis]

To add to that, I've just read a chapter in my book (one I skipped) that says that dynamic class loading cannot occur without a security file. Does this apply when the server and client are on the same machine?

I think I know the answer and am just running this into the ground. I think my implementation is safe and does no use dynmic class loading. One thing I will change; I'm going to copy my service interface into both the server and client package. That way the two packages are completeley independent of one another.

[Daniel Dalton]

Hi Eric - have a look at this earlier post. Andrew kindly obtained confirmation that dynamic proxies are not permitted:

Dynamic proxies

[Andrew Monkhouse]

Hi Eric

How do I know if it's being used? Any RMI expert could probably answer yes or no. Yes your current implementation is dynamically loading the class or no your fine.

The yes/no type answer is going to come back to whether or not your client can access the stub files from the local machine. Since your stubs will be in the runme.jar file, the client will be able to access them directly, so no dynamic loading will be required.

If you wanted confirmation on your screen of this, you will need to start the rmiregistry and the server application with debug mode turned on. You will then be able to see the requests for the server and/or the stubs (if requested). You would probably want to set up a test case that requires dynamic loading of stubs just so you can see what messages you should get, then run your standard SCJD application and confirm that you don't get the dynamic loading of stubs.

I don't recall anyone in this forum asking about how to do this in the past - I would think that most candidates are happy with the theoretical "stubs are in the classpath / no dynamic loading occurs" answer.

Regards, Andrew

[Eric Ellis]

Hey, really... thanks guys. I'm totally with you on the dynamic proxies. I'm going to generate a new version of my stubs right now and use debug mode to make sure their being used.

[Eric Ellis]

??? I guess I'm stuck. I'm using sun.rmi.loader.logLevel to monitor dynamic class loading. It was no problem to get my server to use the rmic generated stub but my client won't take. It seems like no matter what I do the client dynamically loads the stub class. Here is what the output looks like on the client:

Nov 14, 2005 11:22:52 AM sun.rmi.server.LoaderHandler loadClass
FINE: AWT-EventQueue-0: name = "suncertify.server.DataServiceImpl_Stub", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@133056f
Nov 14, 2005 11:22:52 AM sun.rmi.server.LoaderHandler loadClass
FINE: AWT-EventQueue-0: name = "java.rmi.server.RemoteStub", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@133056f
Nov 14, 2005 11:22:52 AM sun.rmi.server.LoaderHandler loadClass
FINE: AWT-EventQueue-0: name = "java.rmi.server.RemoteObject", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@133056f
Nov 14, 2005 11:22:52 AM sun.rmi.server.LoaderHandler loadClass
FINE: AWT-EventQueue-0: name = "java.rmi.dgc.Lease", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@133056f
etc, etc, etc... -------------->

The first two lines are of interest. Everything else is related to support classes and garbage collection.

I've looked at a lot of postings and nobody has been clear about exactly how to get the client to read the server's stub. Would I need to place an explicit reference in my "DataServiceClient" class? I tried dropping the stub in the client directory, re-compiling the stub source using the .client package, and about five other obscure... what-if's.

I hope some of you have ideas.

Please don't write back telling me about the codebase and the registry. My implementation does not run the server and the registry as seperate processes (technically it does but you know what I mean).

Thanks in advance

[Eric Ellis]

After further research I'm going to conclude that this is the correct behavior for RMI implementations prior to version 1.5.

CORE JAVA 2

server:
ProductServer.class <launch code>
ProductImpl.class
Product.class <interface>
ProductImpl_Stub.class

client:
ProductClient.class <launch code>
Product.class <interface>

The stub is always dynamically loaded from the registry to the client.

So ... I spent six hours testing this and in the end nothing has changed. I'm going to kick some ass if I end up being wrong; having an automatic failure.

A note to anyone who finds this message useful. It was six hours well spent; learning how to debug RMI.