In JDK 1.1 code in the class path is trusted and can perform any operation; downloaded code is governed by the rules of the installed security manager. If you run this example in JDK 1.2, you need to specify a policy file when you run your server and client. Here is a example-1dot2/java.policygeneral policy file that allows downloaded code, from any code base, to do two things:
Here is the code for the general policy file: grant { permission java.net.SocketPermission *:1024-65535, "connect,accept; permission java.net.SocketPermission *:80, "connect; };
If you make your code available for downloading via HTTP URLs, you should use the preceding policy file when you run this example. However, if you use file URLs instead, you can use the example-1dot2/java.policy2following policy file Note that in Windows-style file names, the backslash character needs to be represented by two backslash characters in the policy file. grant { permission java.net.SocketPermission *:1024-65535, "connect,accept; permission java.io.FilePermission "c:\\home\\ann\\public_html\\classes\\-, "read; permission java.io.FilePermission "c:\\home\\jones\\public_html\\classes\\-, "read; };
This example assumes that the policy file is called
java.policy and that it contains the appropriate
permissions. If you run this example on JDK 1.1, you will not need to
use a policy file, since the RMISecurityManager provides
all of the protection you need.
rmiregistry command. As discussed earlier, the
RMI registry is a simple server-side bootstrap naming facility that
allows remote clients to get a reference to a remote object. Note that
before you start the rmiregistry, you must make sure that
the shell or window in which you will run rmiregistry
either has no CLASSPATH environment variable set or has a
CLASSPATH environment variable that does not include the
path to any classes, including the stubs for your remote object
implementation classes, that you want downloaded to clients of your
remote objects.
If you do start the rmiregistry and it
can find your stub classes in CLASSPATH, it will
not remember that the loaded stub class can be loaded from your
server's code base, specified by the
java.rmi.server.codebase property when you started up your
server application. Therefore, the rmiregistry will not
convey to clients the true code base associated with the stub class
and, consequently, your clients will not be able to locate and to load
the stub class or other server-side classes.
To start the registry on the server, execute the
rmiregistry command. This command produces no output and
is typically run in the background. For this example, we will start the
registry on the host zaphod.
javaw if start is not available):
By , the registry runs on port 1099. To start the registry on a
different port, specify the port number on the command line. Do not
forget to unset your CLASSPATH.
Once the registry is started, you can start the server. First, you need
to make sure that both the compute.jar file and the remote
object implementation class (since that is what you are starting) are
in your class path.
When you start the compute engine, you need to specify, using the
java.rmi.server.codebase property, where the server's
classes will be made available. In this example the server-side classes
to be made available for downloading are the
ComputeEngine's stub and the Compute and the
Task interfaces, available in ann's
public_html\classes directory. Here, we start the compute
engine server on the host zaphod, the same host where we
started the registry.
The preceding java command defines several properties.
java.rmi.server.codebase property specifies the
location, a code base URL, of classes originating
from this server so that class information for
objects sent to other virtual machines will include the location of the
class so that a receiver can load it. If the code base specifies a
directory (as opposed to a JAR file), you must include the trailing
slash in the code base URL.
java.rmi.server.hostname property indicates the
fully qualified host name of your server. In some networked
environments a fully qualified host name is not obtainable by using the
Java APIs. RMI makes a best-effort attempt to obtain the fully
qualified host name. If one cannot be determined, it will fall back and
use the IP address. To ensure that RMI will use a host name that is
usable from potential clients, you may want to set the
java.rmi.server.hostname property as a safety measure.
java.security.policy property is used to specify
the policy file that contains the permissions you intend to grant
specific code bases.
The ComputeEngine's stub class is dynamically loaded into
a client's virtual machine only when the class is not already available
locally and the
java.rmi.server.codebas e property has been set properly,
to the network-accessible location of the stub class, when the server is started. Once such a stub is loaded, it
will not need to be reloaded for additional references to
Com-puteEngine's objects.
Pi class), using the java.rmi.server.codebase
property
Compute remote
object--and the number of decimal places to use in the
rmi/pi 9 9 calculation
java.security.policy property, used to specify
the policy file that contains the permissions you intend to grant
specific code bases
First, set the CLASSPATH to see jones's
client and the JAR file containing the interfaces. Then start the
client on another host (one named ford, for example) as
follows:
Note that the class path is set on the command line so that the
interpreter can find jones's client and the JAR file
containing the interfaces.
After starting the client, you should see the following output on your display: 3.14159265358979323846
The following figure illustrates where the rmiregistry,
the ComputeEngine server, and the ComputePi
client obtain classes during program execution.
When the ComputeEngine server binds its remote object
reference in the registry, the registry downloads the
ComputeEngine_Stub, as well as the Compute
and the Task interfaces on which the stub class depends.
These classes are downloaded from the ComputeEngine's web
server or file system, as the case may be.
The ComputePi client loads the
ComputeEngine_Stub, also from the
Compute-Engine's web server, as a result of the
Naming.lookup call. Since the ComputePi
client has both the Compute and the Task
interfaces available in its class path, those classes are loaded from
the class path, not the remote location.
Finally, the Pi class is loaded into the
ComputeEngine's virtual machine when the Pi
object is passed in the executeTask remote call to the
ComputeEngine object. The Pi class is loaded
from the client's web server.
Bhopal news
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100