1

This is the whole exception:

Computeappengine exceptionRemoteException occurred in server thread; nested exception is: 
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: 
java.lang.ClassNotFoundException: Client.prog (no security manager: RMI class loader disabled)
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: 
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: 
java.lang.ClassNotFoundException: Client.prog (no security manager: RMI class loader disabled)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:334)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at Engine.ComputeappEngine_Stub.executeTask(Unknown Source)
at Client.computeappprog.main(computeappprog.java:23)
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: 
java.lang.ClassNotFoundException: Client.prog (no security manager: RMI class loader disabled)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassNotFoundException: Client.prog (no security manager: RMI class loader disabled)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:373)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:163)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:306)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:288)
... 9 more

My client package contains two classes Computeappproj which contains main also and prog

I already searched 1000 of forums. Nothing helped.

Hoping for something positive

and good

may be...

Luiggi Mendoza
  • 85,076
  • 16
  • 154
  • 332
pcc
  • 81
  • 1
  • 1
  • 8
  • 1
    your server doesn't have the class definition for "Client.prog". the error message seems pretty straightforward. presumably, the "Client.prog" class is being sent between client and server, so both apps need it in the classpath. – jtahlborn Jun 27 '13 at 19:18

2 Answers2

6

The problem actualy lies in a classloading. When you're transferring some non-jdk objects (i.e. objects of your own classes) via RMI you need to ensure, that both JVMs, client and server, has your custom class in a classpath. In your case server lacks Client.prog class, so it's unable to reconstruct an object from binary representation - Client.prog class bytecode is necessary for that. There are generally two ways to resolve this issue:

  1. Easy one: copy all your data transfer object classes to both client's and servers's classpath. So none of them will be confused with unknown classes. For a somewhat serious you might even want to create a separate JAR with DTO classes for the ease of maintenance.

  2. Challenging one: enable remote classloading. In short, this technique enables your server to download class bytecode from a client and vice versa, if necessary. This option has a clear security issue (dowloading potentialy unsafe code), so it's disabled by default. To enable it you should use -Djava.rmi.server.codebase property with URL defined and set an appropriate classloader (RMIClassloader or it's descendant) to make Java security system happy. Here's the useful link with some background theory and troubleshooting guide: link

Jk1
  • 11,233
  • 9
  • 54
  • 64
  • 1
    1. is far and away the best solution unless you _really, truly_ need dynamic class loading (which most RMI apps do _not_ need). – jtahlborn Jun 27 '13 at 19:27
1

I am running a RMI application and no security manager: RMI class loader disabled exception comes

No. Read the stack trace again. The exception here is java.lang.ClassNotFoundException: Client.prog. The stuff in brackets is merely a (literally parenthetical) comment on one of many possible causes.

The problem is that Client.prog isn't on the CLASSPATH of the server. You can tell that from the line:

java.rmi.ServerException: RemoteException occurred in server thread

The solution is to either deploy the class to the server or use the codebase feature.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • no,it isn't a classpath problem..Actually i didn't set the security manager in ma server which didn't let ma server load client's class dynamically a security manager is must for doing that. moreover, prog is a client side class ,so its path shouldn't be set on server side. i solved the problem myself by some experiments. thanx for your help... – pcc Jun 30 '13 at 13:47
  • @pcc It is indeed a classpath problem, which you can *solve* with the codebase feature, which in turn requires a security manager. Your statement beginning 'moreover' is unmotivated and incorrect. – user207421 Apr 09 '14 at 01:31