Spec-Zone .ru
спецификации, руководства, описания, API

rmid - The Java RMI Activation System Daemon

rmid starts the activation system daemon that allows objects to be registered and activated in a Java virtual machine (JVM).

SYNOPSIS

rmid [options]

DESCRIPTION

The rmid tool starts the activation system daemon. The activation system daemon must be started before activatable objects can be either registered with the activation system or activated in a JVM. See the RMI Specification and Activation tutorials for details on how to write programs that use activatable remote objects.

The daemon can be started by executing the rmid command, and specifying a security policy file, as follows:

    rmid -J-Djava.security.policy=rmid.policy

Note: When running Sun's implementation of rmid, by default you will need to specify a security policy file so that rmid can verify whether or not the information in each ActivationGroupDesc is allowed to be used to launch a JVM for an activation group. Specifically, the command and options specified by the CommandEnvironment and any Properties passed to an ActivationGroupDesc's constructor must now be explicitly allowed in the security policy file for rmid. The value of the sun.rmi.activation.execPolicy property dictates the policy that rmid uses to determine whether or not the information in an ActivationGroupDesc may be used to launch a JVM for an activation group.

Executing rmid by default

To specify an alternate port for the registry, you must specify the -port option when starting up rmid. For example,
    rmid -J-Djava.security.policy=rmid.policy -port 1099
starts the activation system daemon and a registry on the registry's default port, 1099.

OPTIONS

-C<someCommandLineOption>
Specifies an option that is passed as a command-line argument to each child process (activation group) of rmid when that process is created. For example, you could pass a property to each Java virtual machine spawned by the activation system daemon:
    rmid -C-Dsome.property=value
This ability to pass command-line arguments to child processes can be useful for debugging. For example, the following command:
    rmid -C-Djava.rmi.server.logCalls=true
will enable server-call logging in all child JVMs.

-J<someCommandLineOption>
Specifies an option that is passed to the java interpreter running rmid. For example, to specify that rmid use a policy file named rmid.policy, the -J option can be used to define the java.security.policy property on rmid's command line, for example:
    rmid -J-Djava.security.policy=rmid.policy
-J-Dsun.rmi.activation.execPolicy=<policy>
Specifies the policy that rmid employs to check commands and command-line options used to launch the JVM in which an activation group runs. Please note that this option exists only in Sun's implementation of the RMI activation daemon. If this property is not specified on the command line, the result is the same as if -J-Dsun.rmi.activation.execPolicy=default were specified. The possible values of <policy> can be default, <policyClassName>, or none:

  • default (or if this property is unspecified)

    The default execPolicy allows rmid to execute commands with specific command-line options only if rmid has been granted permission to execute those commands and options in the security policy file that rmid uses. Only the default activation group implementation can be used with the default execution policy.

    rmid launches a JVM for an activation group using the information in the group's registered activation group descriptor, an ActivationGroupDesc. The group descriptor specifies an optional ActivationGroupDesc.CommandEnvironment which includes the command to execute to start the activation group as well as any command line options to be added to the command line. By default, rmid uses the java command found in java.home. The group descriptor also contains properties overrides that are added to the command line as options defined as:

        -D<property>=<value>
    

    The permission com.sun.rmi.rmid.ExecPermission is used to grant rmid permission to execute a command, specified in the group descriptor's CommandEnvironment to launch an activation group. The permission com.sun.rmi.rmid.ExecOptionPermission is used to allow rmid to use command-line options, specified as properties overrides in the group descriptor or as options in the CommandEnvironment, when launching the activation group.

    When granting rmid permission to execute various commands and options, the permissions ExecPermission and ExecOptionPermission need to be granted universally (i.e., granted to all code sources).

    ExecPermission

    The ExecPermission class represents permission for rmid to execute a specific command to launch an activation group.

    Syntax
    The name of an ExecPermission is the path name of a command to grant rmid permission to execute. A path name that ends in "\*" indicates all the files contained in that directory (where "\" is the file-separator character, File.separatorChar). A path name that ends with "\-" indicates all files and subdirectories contained in that directory (recursively). A path name consisting of the special token "<<ALL FILES>>" matches any file.

    Note: A path name consisting of a single "*" indicates all the files in the current directory, while a path name consisting of a single "-" indicates all the files in the current directory and (recursively) all files and subdirectories contained in the current directory.

    ExecOptionPermission

    The ExecOptionPermission class represents permission for rmid to use a specific command-line option when launching an activation group. The name of an ExecOptionPermission is the value of a command line option.

    Syntax
    Options support a limited wildcard scheme. An asterisk signifies a wildcard match, and it may appear as the option name itself (i.e., it matches any option), or an asterisk may appear at the end of the option name only if the asterisk follows either a "." or "=".

    For example: "*" or "-Dfoo.*" or "-Da.b.c=*" is valid, "*foo" or "-Da*b" or "ab*" is not.

    Policy file for rmid

    When granting rmid permission to execute various commands and options, the permissions ExecPermission and ExecOptionPermission need to be granted universally (i.e., granted to all code sources). It is safe to grant these permissions universally because only rmid checks these permissions.

    An example policy file that grants various execute permissions to rmid is:

    grant {
        permission com.sun.rmi.rmid.ExecPermission
    	"c:\\files\\apps\\java\\jdk1.2.2\\win32\\bin\\java";
    
        permission com.sun.rmi.rmid.ExecPermission
    	"c:\\files\\apps\\java\\jdk1.2.2\\win32\\bin\\java_g";
    
        permission com.sun.rmi.rmid.ExecPermission
    	"c:\\files\\apps\\rmidcmds\\*";
    
        permission com.sun.rmi.rmid.ExecOptionPermission
    	"-Djava.security.policy=c:\\files\\policies\\group.policy";
    
        permission com.sun.rmi.rmid.ExecOptionPermission
    	"-Djava.security.debug=*";
    
        permission com.sun.rmi.rmid.ExecOptionPermission
    	"-Dsun.rmi.*";
    };
    
    The first two permissions granted allow rmid to execute the 1.2.2 version of the java and java_g commands, specified by their explicit path names. Note that by default, the version of the java command found in java.home is used (the same one that rmid uses), and does not need to be specified in the policy file. The third permission allows rmid to execute any command in the directory c:\files\apps\rmidcmds\.

    The fourth permission granted, an ExecOptionPermission, allows rmid to launch an activation group that defines the security policy file to be c:\files\policies\group.policy. The next permission allows the java.security.debug property to be used by an activation group. The last permission allows any property in the sun.rmi property name hierarchy to be used by activation groups.

    To start rmid with a policy file, the java.security.policy property needs to be specified on rmid's command line, for example:

  • rmid -J-Djava.security.policy=rmid.policy

  • <policyClassName>

    If the default behavior is not flexible enough, an administrator can provide, when starting rmid, the name of a class whose checkExecCommand method is executed in order to check commands to be executed by rmid.

    The policyClassName specifies a public class with a public, no-argument constructor and an implementation of the following checkExecCommand method:

        public void checkExecCommand(ActivationGroupDesc desc,
                                     String[] command)
    	throws SecurityException;
    
    Before launching an activation group, rmid calls the policy's checkExecCommand method, passing it the activation group descriptor and an array containing the complete command to launch the activation group. If the checkExecCommand throws a SecurityException, rmid will not launch the activation group and an ActivationException will be thrown to the caller attempting to activate the object.

  • none

    If the sun.rmi.activation.execPolicy property value is "none", then rmid will not perform any validation of commands to launch activation groups.

    -log dir
    Specifies the name of the directory the activation system daemon uses to write its database and associated information. The log directory defaults to creating a directory, log, in the directory in which the rmid command was executed.

    -port port
    Specifies the port rmid's registry uses. The activation system daemon binds the ActivationSystem, with the name java.rmi.activation.ActivationSystem, in this registry. Thus, the ActivationSystem on the local machine can be obtained using the following Naming.lookup method call:
        import java.rmi.*; 
        import java.rmi.activation.*;
    
        ActivationSystem system; system = (ActivationSystem)
        Naming.lookup("//:port/java.rmi.activation.ActivationSystem");
    

    -stop
    Stops the current invocation of rmid, for a port specified by the -port option. If no port is specified, it will stop the rmid running on port 1098.

  • ENVIRONMENT VARIABLES

    CLASSPATH
    Used to provide the system a path to user-defined classes. Directories are separated by colons on UNIX and Macintosh and by semicolons on Win95. For example:
        .;C:\usr\local\java\classes
    

    SEE ALSO

    rmic, CLASSPATH, java