Package wt.manager

Class BaseServerLauncher

java.lang.Object
wt.manager.BaseServerLauncher
Direct Known Subclasses:
MethodServerLauncher
public class BaseServerLauncher extends Object
Class that encapsulates server launches providing string substitution of unique server ids and a variety of other functionalities.

Note that the ids are for use cases where the id must be known prior to creation of the process and these ids are simply unique ids from a sequence, not process/JVM ids.

The launch method takes a service launch command string and replaces occurrences of "{0}" with the current server id, "{1}" with the service_name provided to the constructor, "{2}" with the current time, and "{3}" with a number generated by a rotating sequence between wt.manager.cmd.{service_name}.seq.1.min and wt.manager.cmd.{service_name}.seq.1.max wt.properties values inclusive. "4", "5", "6", "7", "8", "9", and "10" are replaced by the values of wt.manager.cmd.{service_name}.param.4, wt.manager.cmd.{service_name}.param.5, and so on. Where these properties are not specified the values of wt.manager.cmd.param.4, wt.manager.cmd.param.5, and so on are used as defaults. This is all done via MBeanUtilities's formatMessage() utility method which in turn uses MessageFormat so further formatting is possible as per that class.

If the wt.manager.cmd.{service_name}.singleton.enforce wt.properties entry is specified as "true", then this class will not launch a second process for the given service_name as long as any former processes launched by this launcher (and from this JVM) are still running. For the special case where service_name is "BackgroundMethodServer", a value of "true" is assumed for this property unless a value in explicitly specified. Note, however, that this singleton enforcement will not work on Windows if the service in question (e.g. the BackgroundMethodServer) is being launched in a cmd.exe window. [This is due to the odd process behavior of cmd.exe in this case; the initially launched cmd.exe process quickly terminates even though the command it is running and its window continue to run.]

This class also provides special functionality based on wt.manager.cmd.{service_name}.stdout.file and wt.manager.cmd.{service_name}.stderr.file wt.properties entries. If these properties are unset, then nothing changes from "normal" behavior. If they are set to an empty string, then the child processes' stdout and/or stderr is actively consumed. If they are set to a non-empty string, then the {n} substitution noted above is performed and the result is assumed to be a valid file path to which stdout and/or stderr should be captured. Note that both stderr and stdout can be captured to the same file.

In conjunction with these properties, wt.manager.cmd.{service_name}.maxCaptureFilesize will determine the maximum size of the capture files in MB prior to them being segmented (see RollingFileOutputStream). This defaults to 10MB, but can be set to "0" to avoid such segmentation entirely if desired.

If any stdout and/or stderr capture is requested it will be performed by an additional, intermediary sub-process if wt.manager.cmd.{service_name}.noExtraSubProcess is set to "false", otherwise threads within the parent process will be used instead of using a subprocess. This latter behavior avoids creating an extra process, but burdens the originating process with extra threads and links the stdout/err reading lifespan to that of the originating process).

When wt.manager.cmd.{service_name}.redirJvmOpts is specified then its contents are interpreted as a whitespace-delimited list of JVM options to be provided to the intermediate redirection subprocess. [The -classpath option is already handled internally.]

Supported API: true
Extendable: false

  • Constructor Details

    • BaseServerLauncher

      public BaseServerLauncher(String service_name)
      Constructor currently used by ServerLauncher.

      Supported API: true

  • Method Details

    • launch

      public Process launch(String origCmd) throws Exception
      Called by wt.manager.ServerLauncher with the wt.manager.cmd.{serviceName} property; note that it also uses the returned Process to waitFor() the child process where appropriate. Supported API: true
      Throws:
      Exception