RMI Registry Issue: rmiregistry may cause unintended exceptions when binding with codebase using the "file:" URL scheme

Question

Please see the passage "RMI Registry Issue" of this article for the background on Java Update 1.6.0_29 first.

If I understand correctly (I'm german), the update introduces a bug in the rmiregistry which fails to work with the file: pattern in the codebase.

I.E. the following won't work any more with 1.6.0_29:

-Djava.rmi.server.codebase="file:myproject/bin/ ..."

We are currently using the feature of having a codebase with file: syntax. Does anyone know a workaround for making this work?

Note: No, we do not want to start a local webserver or ftp server.

Update:

On Naming.bind this exception is thrown:

java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: 
    java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: 
    java.lang.ClassNotFoundException: access to class loader denied
    at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:400)
    at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:248)
    at sun.rmi.transport.Transport$1.run(Transport.java:159)
    at java.security.AccessController.doPrivileged(Native Method)

Thermionic

You either have to use a different scheme: in your codebase or not use the codebase feature at all. – Prosthodontics

Answer 1

I had the same problem, and can confirm that downgrading JDK to earlier version solves the problem. I know, it's not a solution you're looking for, but at least it makes it to work.

Allisan

Since which version exactly does this bug occur? I want to downgrade, but don't know to which version. – Aguayo

Answer 2

Take running in windows as an example:

Step 1. In C:\Users\Jimmy.java.policy (create it if not exist), append below content:

grant { permission java.security.AllPermission; };

Of course "C:\Users\Jimmy\" is the user home, please change to your home accordingly. Adding AllPermission is just for quick resolving your issue. you'd better config a more accurate FilePermission here.

---

Step 2. Start rmiregistry:

C:\JDK\bin>rmiregistry -J-Djava.rmi.server.codebase=file://C:/workspaces/MyLab/target/classes/

(Please note codebase must ended with "/")

---

Step 3. Run your server and client program.

References:

http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/codebase.html http://docs.oracle.com/javase/7/docs/technotes/guides/security/spec/security-spec.doc3.html http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html

Cinematograph

Answer 3

It looks like there is no workaround because it is a bug, so wait for the fix

See details at

https://bugzilla.redhat.com/show_bug.cgi?id=751203

Code fix http://icedtea.classpath.org/hg/icedtea6/rev/67df573b0734

Dandrea

Answer 4

If you do not need dynamic code downloading (in which case you can use ftp codebase) the solution is simply to set CLASSPATH environment variable to the path to your jar file:

Windows: set CLASSPATH="path_to_jarfile"

Linux (batch): CLASSPATH="path_to_jarfile" export CLASSPATH

Best place to do it is in some script that invokes the RMI server. Setting class path in the command line (-cp option) when starting RMI server does not help because it does not affect rmiregistry classpath!

Lesleelesley

Answer 5

If you start the rmiregistry in the working directory of your project, it works. So essentially working directory of your project and current directory for rmiregistry should be same.

Primer

Answer 6

I recently encountered this issue as well. I can confirm that when using the file: protocol the rmiregistry must either:

• be started in the root of the directory containing the shared classes; or
• set the classpath to point to the shared classes or shared class jar; or
• use a protocol other than file:// (I set up ngnix and served the jar from that).

Connally

Answer 7

Maybe not what you want, but you could resolve this with classpath rather than codebase. The client JVM will work fine if you add the required classes to its classpath. If you are using the file: URL scheme, then the classes must already be available on the localhost.

Ludwig

No, this doesn't work. When calling Naming.bind the above mentioned exception is thrown. And the classes are in the classpath :-) – Thermionic

Answer 8

I had the same problem but I couldn't change the JDK version. Turns out you can solve it by running/starting the rmiregistry from the same directory as your code base, which in my case was target/classes. So cd project/target/classes and then run rmiregistry &

Niacin