rmid
Sorry, no description
... the author of this command may not have provided any manuals
Once you know what this command is about, feel free to add a description in the input "add an example + trick and tips" below
help other Linux-fans !
see also :
rmic - java
Synopsis
rmid
[options]
add an example, a script, a trick and tips
examples
no example yet ...
... Feel free to add your own example above to help other Linux-lovers !
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 VM. See the Java RMI Specification @
http://docs.oracle.com/javase/7/docs/platform/rmi/spec/rmiTOC.html
and Activation tutorials @
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/activation/overview.html
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 VM 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 VM for an activation group.
Executing
rmid by default
o
starts the Activator and an internal registry on the
default port, 1098, and
o
binds an ActivationSystem to the name
java.rmi.activation.ActivationSystem in this internal
registry.
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.
Starting
rmid from inetd/xinetd
An alternative to starting rmid from the command line
is to configure inetd (Solaris) or xinetd
(Linux) to start rmid on demand.
When
rmid starts up, it attempts to obtain an inherited
channel (inherited from inetd/xinetd) by
invoking the System.inheritedChannel method. If the
inherited channel is null or not an instance of
java.nio.channels.ServerSocketChannel, then
rmid assumes that it was not started by
inetd/xinetd, and it starts up as described
above.
If the
inherited channel is a ServerSocketChannel instance,
then rmid uses the java.net.ServerSocket
obtained from the ServerSocketChannel as the server
socket that accepts requests for the remote objects it
exports, namely the registry in which the
java.rmi.activation.ActivationSystem is bound and the
java.rmi.activation.Activator remote object. In this
mode, rmid behaves the same as when it is started
from the command line, except:
o
Output printed to
System.err is redirected to a file. This file is
located in the directory specified by the
java.io.tmpdir system property (typically
/var/tmp or /tmp) with the prefix
"rmid-err" and the suffix
"tmp".
o
The -port option is disallowed. If this
option is specified, rmid will exit with an error
message.
o
The -log option is required. If this option
is not specified, rmid will exit with an error
message.
See the man
pages for inetd (Solaris) or xinetd (Linux)
for details on how to configure services to be started on
demand.
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
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 VMs.
-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 VM in which an activation group
runs. Please note that this option exists only in
Sun’s implementation of the Java 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:
o
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 VM 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
"/files/apps/java/jdk1.7.0/solaris/bin/java";
permission
com.sun.rmi.rmid.ExecPermission
"/files/apps/rmidcmds/*";
permission
com.sun.rmi.rmid.ExecOptionPermission
"-Djava.security.policy=/files/policies/group.policy";
permission
com.sun.rmi.rmid.ExecOptionPermission
"-Djava.security.debug=*";
permission
com.sun.rmi.rmid.ExecOptionPermission
"-Dsun.rmi.*";
};
The first permission granted allow rmid to execute
the 1.7.0 version of the java command, specified by
its explicit path name. 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 second permission
allows rmid to execute any command in the directory
/files/apps/rmidcmds.
The third
permission granted, an ExecOptionPermission, allows
rmid to launch an activation group that defines the
security policy file to be
/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
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.
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. For example:
.:/usr/local/java/classes
see also
rmic ,
CLASSPATH @
http://docs.oracle.com/ java se/7/docs/technotes/tools/index.html#classpath,
java