None of the primary properties are required, and all have 'reasonable' defaults. When using Quartz via RMI, you
need to start an instance of Quartz with it configured to "export" its services via RMI. You then create clients to the
server by configuring a Quartz scheduler to "proxy" its work to the server.
If you want the Quartz Scheduler to export itself via RMI as a server then set the 'rmi.export' flag to true.
The host at which the RMI Registry can be found (often 'localhost').
The port on which the RMI Registry is listening (usually 1099).
Set the 'rmi.createRegistry' flag according to how you want Quartz to cause the creation of an RMI Registry. Use "false"
or "never" if you don't want Quartz to create a registry (e.g. if you already have an external registry running). Use
"true" or "as_needed" if you want Quartz to first attempt to use an existing registry, and then fall back to creating
one. Use "always" if you want Quartz to attempt creating a Registry, and then fall back to using an existing one. If a
registry is created, it will be bound to port number in the given 'org.quartz.scheduler.rmi.registryPort' property, and
'org.quartz.rmi.registryHost' should be "localhost".
The port on which the the Quartz Scheduler service will bind and listen for connections. By default, the RMI service
will 'randomly' select a port as the scheduler is bound to the RMI Registry.
If you want to connect to (use) a remotely served scheduler, then set the 'org.quartz.scheduler.rmi.proxy' flag to true.
You must also then specify a host and port for the RMI Registry process - which is typically 'localhost' port 1099.
It does not make sense to specify a 'true' value for both 'org.quartz.scheduler.rmi.export' and
'org.quartz.scheduler.rmi.proxy' in the same config file - if you do, the 'export' option will be ignored. A value of
'false' for both 'export' and 'proxy' properties is of course valid, if you're not using Quartz via RMI.