Server-Side Changes Using Dynamic Classloadingin an Application

class server anyway. Neither of these is a compelling argument, but they make the decision to require a separate class server seem more reasonable.

19.5.1 Server-Side Changes

The main change on the server side involves explicitly declaring the codebase. This is done by setting the java.rmi.server.codebase system parameter. java.rmi.server.codebase should be set to a string that contains a space-delimited sequence of URLs. For example, the following command-line invocation sets the codebase to http:localHost:80 : start java -Djava.security.manager - Djava.rmi.server.codebase=http:localhost:80 -Djava.security.policy=d:\\java.policy com.ora.rmibook.chapter9.applications. ImplLauncher Bob 10000 Alex 1223 RMI uses the value of java.rmi.server.codebase when trying to annotate class descriptions for serialized objects. RMI uses the following rules for determining which annotation is sent with a class description: • If a class was loaded from the filesystem, and java.rmi.server.codebase is set, then the annotation for that class is equal to the value of java.rmi.server.codebase . • If a class was loaded from the filesystem, and java.rmi.server.codebase has not been set, the class is not annotated at all. • If a class wasnt loaded from the filesystem but was instead loaded via dynamic classloading, the original annotation, which was used to load the class in the first place, is retained and sent as the class annotation. Ordinarily, it suffices to set the java.rmi.server.codebase property from the command line, as in the preceding example. In addition, setting java.rmi.server.codebase from the command line preserves flexibility. However, there is one code change that may be necessary if the servers in question are being launched by the activation framework. Heres the code from Chapt er 17 that created an activation group: private static void createActivationGroup throws ActivationException, RemoteException { ActivationGroupID oldID = ActivationGroup.currentGroupID ; Properties pList = new Properties ; pList.putjava.security.policy, d: \\java.policy; pList.putsun.rmi.transport.connectionTimeout, 30000; ActivationGroupDesc.CommandEnvironment configInfo = null; ActivationGroupDesc description = new ActivationGroupDescpList, configInfo; ActivationGroupID id = ActivationGroup.getSystem . registerGroupdescription; ActivationGroup.createGroupid, description, 0; return; } In the middle of this code, pList is created and filled with the values of system properties for the JVM that will be launched by the Activation Framework. If the application is going to use dynamic classloading, then pList must also contain an entry for the java.rmi.server.codebase property. The following code sets the value for java.rmi.server.codebase in pList to whatever the launching JVMs value for java.rmi.server.codebase is: private static void createActivationGroup throws ActivationException, RemoteException { ActivationGroupID oldID = ActivationGroup.currentGroupID ; Properties pList = new Properties ; pList.putjava.security.policy, d:\\java.policy; pList.putsun.rmi.transport.connectionTimeout, 30000; String codebase = System.getProperty ; if null=codebase 0=codebase.length { pList.putjava.rmi.server.codebase, codebase; } ActivationGroupDesc.CommandEnvironment configInfo = null; ActivationGroupDesc description = new ActivationGroupDescpList, configInfo; ActivationGroupID id = ActivationGroup.getSystem . registerGroupdescription; ActivationGroup.createGroupid, description, 0; return; } You probably noticed when we started the servers that we also amended our security policy. This was necessary in order to prevent security exceptions from being thrown when the client attempts to make a connection to the registry or the server. Well talk more about security policies in the next chapter. In the meantime and only for the meantime, just use the following for the security policy file: grant { permission java.security.AllPermission; };

19.5.2 Naming-Service Changes