RMI problem
Slavko Vorkapitch
'Distributed Java' by Jim Farley (maybe I should ask him ?)-
On line 21 where he names the remote program "TheSolver", I keep
getting
an exception :
1) If I leave the string name as "TheSolver" I get a
java.net.SocketPermission 127.0.0.1:1099 connect,resolve) exception
or 2) if I try String name = "rmi://vail/The Solver";
where "vail" is the remote server on my lan. I get a
Caught an exception looking up Solver.java.net.MalformedURLException:
invalid UR
L string: rmi://vail/The Solver
Everyting on the server seems as should be. Can somebody clue me in as
to what a properly formed URL should look like for a RMI registered
service named "TheSolver" on a machine named "vail" ??
Thanks in advance,
El Squid
Tom Cole
Ingo Pakleppa
Vorkapitch) wrote:
>Hi - I am trying to get a simple RMI example (3-14) going from chap 3
>'Distributed Java' by Jim Farley (maybe I should ask him ?)-
>
>On line 21 where he names the remote program "TheSolver", I keep
>getting
>an exception :
>
>1) If I leave the string name as "TheSolver" I get a
>java.net.SocketPermission 127.0.0.1:1099 connect,resolve) exception
>
>or 2) if I try String name = "rmi://vail/The Solver";
>where "vail" is the remote server on my lan. I get a
>Caught an exception looking up Solver.java.net.MalformedURLException:
>invalid UR
>L string: rmi://vail/The Solver
Get rid of the space.
2147483647 Alexander Derazhne
Slavko Vorkapitch wrote in message ...
>java.net.SocketPermission 127.0.0.1:1099 connect,resolve) exception
If You using Java2 - it has little different security model. Create
plain text file <file_name> and put following into it:
========
grant {
permission java.security.AllPermission;
};
========
Then start your server with keys:
-Djava.security.manager -Djava.security.policy=<file_name>
The value for file above is VERY bad. It turn off any security. Use it
for local testing only and never use it in public servers. Learn more about
java security and modify this file to give exact required permissions to
exact code. You will also know how to avoid using special keys in command
line!
Alexander Derazhne
Slavko Vorkapitch
when starting the server on my Linux box:
grant {
permission java.security.AllPermission;
};
grant{
permission java.net.SocketPermission"*:1024-65535","accept,resolve,connect";
};
The last line is theoretically superfluous..
C:\Java>java dcj.rmi.RMISolverClient
Looking up rmi://vail/TheSolver...
Caught an exception looking up Solver.java.security.AccessControlException: acce
ss denied (java.net.SocketPermission vail resolve)
Looks to me like the client program is contacting the registry on my Linux box
but I still have a problem there..
El Squid
"2147483647 Alexander Derazhne" <sa...@antecltd.kiev.ua> wrote in message news:<a5ih9i$oqf$1...@alice.infopulse.kiev.ua>...
2147483647 Alexander Derazhne
Slavko Vorkapitch wrote in message ...
>Hi - I am still getting an exception - even when I use the following policy
file
>when starting the server on my Linux box:
>
>grant {
> permission java.security.AllPermission;
>};
>
>grant{
> permission
java.net.SocketPermission"*:1024-65535","accept,resolve,connect";
>};
>
>The last line is theoretically superfluous..
>
>C:\Java>java dcj.rmi.RMISolverClient
>Looking up rmi://vail/TheSolver...
>Caught an exception looking up Solver.java.security.AccessControlException:
acce
>ss denied (java.net.SocketPermission vail resolve)
>
>Looks to me like the client program is contacting the registry on my Linux
box
>but I still have a problem there..
Now I understand. You successfuly bind server, but client application
can't invoke Naming.lookup(). Have You the following at the begin of main():
System.setSecurityManager(new java.rmi.RMISecurityManager());
?
Alexander Derazhne
Antonio Monetti
new methods and modifying existing methods on server side and I have
generated a new stub class. If I try to connect to a server with a
client that contains an old stub class this ServerException appears:
java.rmi.ServerException: RemoteException occurred in server thread;
nested exception is:
java.rmi.UnmarshalException: invalid method hash
java.rmi.UnmarshalException: invalid method hash
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:245)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:220)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:122)
....
Is it possible to modify a class maintaining backward compatibility for
the generated stub classes? Thanks
Antonio
Slavko Vorkapitch
El Squid
"2147483647 Alexander Derazhne" <sa...@antecltd.kiev.ua> wrote in message news:<a5l5sn$hth$1...@alice.infopulse.kiev.ua>...
Esmond Pitt
> Is it possible to modify a class maintaining backward compatibility for
> the generated stub classes? Thanks
Not if you modify the remote interface, you get 'invalid method hash'.
You should add another remote interface, or use
versioning-by-deriviation:
interface Version1 extends Remote {...}
interface Version2 extends Version1 {...}
class X extends UnicastRemoteObject implements Version1, Version2, ...
That way clients who only know about Version1 will still work.
EJP
2147483647 Alexander Derazhne
Slavko Vorkapitch wrote in message ...
>On the client yes, on the server no.
It's strange. May be the root pf problem is in the Linux security (my
server works on WinNT/2K without any problem) ?
Alexander Derazhne
Slavko Vorkapitch
client as well as the server. Funny thing I was able to correctly
execute both client and server on Win2000 by just using the policy
file specification with the client but Linux required both the policy
file specification on the server and on the Win2000 client... Strange.
Thanks everybody,
El Squid
"2147483647 Alexander Derazhne" <sa...@antecltd.kiev.ua> wrote in message news:<a5nhq7$16n$1...@alice.infopulse.kiev.ua>...
Phil Earnhardt
Vorkapitch) wrote:
>Hi - the solution was to specify a policy file when starting up the
>client as well as the server. Funny thing I was able to correctly
>execute both client and server on Win2000 by just using the policy
>file specification with the client but Linux required both the policy
>file specification on the server and on the Win2000 client... Strange.
Not necessarily strange.
The security policy is needed when you're loading classes over the
network. Depending on how you set up your test case on a single
machine, you may be loading some classes from the network, or you may
simply be loading them from your classpath.
If you are running the client and the server on the same machine, you
must be very careful to ensure that the client's environment is what a
client would see on a remote machine. You must have a classpath for
the client side, and a classspath for the server side.
The O'Reilley text "Java RMI" covers deployment issues in detail. I
highly recommend getting a copy and reading through the pertinent
chapters.
--phil
Paul Roebuck
Phil Earnhardt <p...@dim.com> wrote:
> On 1 Mar 2002 09:18:39 -0800, el_squ...@yahoo.com (Slavko
> Vorkapitch) wrote:
>
> If you are running the client and the server on the same machine, you
> must be very careful to ensure that the client's environment is what a
> client would see on a remote machine. You must have a classpath for
> the client side, and a classspath for the server side.
>
What I have read says to unset the CLASSPATH for the RMI Registry,
and set both java.rmi.server.codebase and java.rmi.server.hostname
for the server.
Phil Earnhardt
Vorkapitch) wrote:
>Hi - the solution was to specify a policy file when starting up the
>client as well as the server. Funny thing I was able to correctly
>execute both client and server on Win2000 by just using the policy
>file specification with the client but Linux required both the policy
>file specification on the server and on the Win2000 client... Strange.
Not necessarily strange.
The security policy is needed when you're loading classes over the
network. Depending on how you set up your test case on a single
machine, you may be loading some classes from the network, or you may
simply be loading them from your classpath.
If you are running the client and the server on the same machine, you
must be very careful to ensure that the client's environment is what a
client would see on a remote machine. You must have a classpath for
the client side, and a classspath for the server side.
The O'Reilley text "Java RMI" covers deployment issues in detail. I
Phil Earnhardt
<roe...@mdanderson.org.invalid> wrote:
>> If you are running the client and the server on the same machine, you
>> must be very careful to ensure that the client's environment is what a
>> client would see on a remote machine. You must have a classpath for
>> the client side, and a classspath for the server side.
>
>What I have read says to unset the CLASSPATH for the RMI Registry,
>and set both java.rmi.server.codebase and java.rmi.server.hostname
>for the server.
If you have an issue with deployment, I'd recommend reading the
pertinent chapter from "Java RMI".
--phil