Publishing Engine Programmer's Guide > The Arbortext Publishing Engine Request Manager > Understanding the Internal Structure of Arbortext PE Request Manager > Initialization > Basic Flow of Control for Initialization
  
Basic Flow of Control for Initialization
When the servlet container calls the Arbortext Publishing Engine servlet's init method, the init method begins by finding the configuration file e3config.xml and parsing the XML document into a set of Java objects rooted in an instance of the class com.arbortext.e3cf.E3Config.
The init method continues by creating an instance of the object com.arbortext.e3.E3RequestContext according to the parameters in e3config.xml. The E3RequestContext constructor performs the following steps:
1. Builds a map of the global parameters specified in web.xml and e3config.xml.
2. Examines the global parameter map. If any parameter is not specified, a default value is stored in the map. As processing proceeds, other values are calculated and stored in the map.
3. Sets the global debug parameter and debug-verbose flags so that tracing produces the desired level of detail.
4. Sets global variables for the location of temporary files and directories.
5. Determines the location of the Arbortext PE sub-process installation, either as specified by the parameter com.arbortext.e3.epicInstallation or relative to the location of the servlet container's web application directory.
6. Initializes the transaction archive and the directory in which transactions directories are created.
7. Initializes the com.arbortext.e3.E3Version object with information about the Arbortext Publishing Engine version, build number, and time and date it was launched
8. Loads, instantiates, and initializes an object for each component defined in e3config.xml, in the order shown in Arbortext PE Request Manager Components.
9. Runs all blocking initializers.
10. Starts a background thread to run all deferred initializers.
Components of the same type are initialized in the order they appear in the e3config.xml configuration file.
For each dynamic component, the com.arbortext.e3.E3RequestContext initializer calls the object’s init method. Each object can use the services provided by the Arbortext Publishing Engine Request Context that have already been initialized. Thus, for example, a cache manager’s init method should not try to allocate an Arbortext PE sub-process because cache managers are initialized before the Arbortext PE sub-process pools. Since the initializers run last, they can assume that all other components have initialized and are available for use.
The process of initializing the Arbortext PE sub-process pools may cause Arbortext PE sub-processes to start running, meaning an Arbortext PE sub-process will start for each pool that is not disabled and that has a minSubprocesses parameter greater than zero.
The process of running initializers may result in transactions being submitted to the request handlers for processing, meaning these transactions look like real transactions submitted from the network, but in fact they are pseudo-transactions submitted by the initializers.
When the thread executing the deferred initializers finishes running, it will start the Queued Transaction Scheduler. From this point, queued transactions may be submitted for execution.
When the com.arbortext.e3.E3RequestContext initializer returns control to the init method, the init method will return to the servlet container. From that point forward, the Arbortext PE Request Manager will be prepared to accept requests from the servlet container (from network clients on the web). The init returns before the deferred initializers have completed execution.
If an error occurs during this initialization process, the method com.arbortext.e3.E3servlet.init will throw a ServletException object. The object tells the servlet container not to pass any requests to the Arbortext PE Request Manager. Instead, the servlet container will call com.arbortext.e3.E3servlet.destroy. If another request arrives for the Arbortext PE Request Manager, the servlet container will attempt to load it again by calling the init method a second time.