Manually Starting WebObjects Applications

You manually start WebObjects applications when load balancing, when debugging applications, when your application requires special adaptors, or for similar reasons. You manually start applications from a shell, a type of program that accepts entered commands. For convenience, the Bourne shell supplied with WebObjects on Windows NT is assumed in this and other procedures.

Syntax and Arguments

The syntax for starting WODefaultApp and compiled WebObjects applications from a shell program is:

ApplicationName [-c] [[-a AdaptorClass] [-n InstanceNumber] [-p PortNumber] [-q ListenQueueDepth]] [-d DocumentRoot] ApplicationDirectory

ApplicationName: The name of the compiled WebObjects application executable to run, or WODefaultApp. You must either connect to the directory containing the executable or supply the path to that directory. Compiled applications must either be located in the document root or in NextLibrary/WOApps. WODefaultApp is located in NextLibrary/Executables.; All WebObjects applications are managed by an application object which, through inheritance from WOApplication, knows how to process the arguments specified on the command line. WODefaultApp is a generic WebObjects application that is used to interpret scripted applications. One WODefaultApp process must run for each instance of a scripted WebObjects application. WODefaultApp will not start an application on a remote host.

-c: Requests that the application cache component definitions (page templates) instead of reparsing HTML, declaration, and script files upon each new HTTP request. By default, applications do not cache component definitions. This setting ensures that during development of scripted applications programmers can modify a component's logic and see the result without having to relaunch the application. If you are deploying applications, however, you should turn on page caching by specifying this flag when you launch the application.

-a AdaptorClass: The class of an adaptor that the application will use to communicate with the server. You can specify multiple adaptors, as long as they are of different types. (For example, you could have a separate adaptor with its own port for communicating directly with Java applets on the browser.) If you specify multiple HTTP adaptors, only the last one specified will be made the active one).

The subsequent three arguments belong to the adaptor specified in AdaptorClass; the first two of these are used in load balancing: You cannot specify adaptor arguments unless you specify an adaptor class.

-n InstanceNumber: A positive integer that uniquely identifies an application instance with which the adaptor will communicate. If you do not specify an instance number, the adaptor specified in AdaptorClass creates one using random number generation. If a URL does not specify the instance number, the application is presumed to run on the server machine as a single instance application, as if it had been autostarted. If you specify AdaptorClass for the purpose of load balancing, you must specify an instance number.

-p PortNumber: Specifies the socket port used to communicate with an application instance. Port numbers must be over 1024 since numbers between zero and 1024 are reserved. If you specify AdaptorClass for the purpose of load balancing, you must specify a port number.

-q ListenQueueDepth: Specifies the queue depth on a TCP/IP socket at the entrance of the application. The default listen-queue depth is 4, meaning that while the application process is handling a request, up to four other requests can be in the socket buffer before the socket starts refusing them. If the application is expected to experience "spikes" in its processing load, it might be a good idea to increase the listen queue depth. Increasing this default does not necessarily improve performance or allow the application to serve more requests at sustained high loads.

-d DocumentRoot: The document root of the server, which can be different from the DOCUMENT_ROOT specified for a given web server. This argument is required and must come right before ApplicationDirectory (that is, it is position-dependent).

ApplicationDirectory: Specifies the directory path of an application relative to DOCUMENT_ROOT/WebObjects. This path is required.

Examples

The following example starts the scripted application TimeOff on Windows NT for the Netscape 1.1 server:

> C:\NeXT\NextLibrary\Executables\WODefaultApp -d C:/NETSCAPE/ns-home/docs 
  Examples/TimeOff

The following example starts a compiled WebObjects example application on Mach, assigning it the default HTTP (CGI) adaptor and specifying port and instance numbers for that adaptor.

> HelloWorldCompiled -a WODefaultAdaptor -n 1 -p 3000 
 -d /NextLibrary/WebServer/htdocs Examples/HelloWorldCompiled

You can start a compiled application in NextLibrary/WOApps but the path to the application in WOApps should match exactly the path to the application under DOCUMENT_ROOT/WebObjects. In other words, if you have an "Examples" directory under DOCUMENT_ROOT/WebObjects, there should be an "Examples" subdirectory in NextLibrary/WOApps.

Notes

Since the Web server uses DocumentRoot and ApplicationDirectory argument to build URLs, you should use forward slashes as opposed to a backslashes when specifying these arguments.

As a convenience, you might create a shell script that starts WebObjects applications when the server machine is booted. You also might create another shell script that you can run at the command line to start applications.

Table of Contents Next Section