Environment Configuration
This chapter describes the structure of the directory that contains environment configuration files, and how to use them to run OpenFrame GW.
1. Directory Structure
The following is the directory structure for JEUS (web application server). The domains directory under $JEUS_HOME includes the servers directory. The servers directory includes the application directory that includes the OpenFrame GW binary.
$JEUS_HOME/domains
+---- <domain_name>
+---- bin
+---- config
+---- lib
+---- servers
+---- <server_name>
+---- bin
+---- logs
+---- lib
+---- application
|---- logback.xml
|---- *.jar
+---- UninstallerData
+---- scripts
+---- webterminal
+---- ofgwconf
|---- ofgw.properties
+---- cpm
+---- license
+---- initScreen
|---- initScreen.txt
|---- vtam.properties
- servers/<server_name>/lib/application
-
Contains ofgw-71-<revision>.jar and other libraries. The logback.xml configuration file is located.
Directory or File Description logback.xml
Configuration file that defines the file format and log level of the log file. For more information, refer to logback.xml.
- servers/<server_name>/lib/application/ofgwconf
-
Contains OpenFrame GW configuration files.
Directory or File Description ofgw.properties
Configuration file that defines OpenFrame GW and WebTerminal environment. For more information, refer to ofgw.properties.
cpm
Directory that contains the CPM file used in the WebTerminal.
license
Directory that contains the OpenFrame GW license file.
initScreen
The initScreen.txt file is saved to display the initial screen when connecting to a terminal. For more information, refer to initScreen.txt.
vtam.properties
Configuration file that supports specifying multi-ports and their corresponding init screens. For more information, refer to vtam.properties.
dhcp.properties
Configuration file that supports automatic LU allocation based on host names in a DHCP environment. For more information, refer to dhcp.properties.
Applications deployed on the web application server are located in the following path:
${JEUS_HOME}/domains/<domain_name>/servers/<server_name>/lib/application/
<application_id>/|
For more information about each directory, refer to "1.1.4. Directory Structure to Manage Applications" of JEUS Applications & Deployment Guide. |
2. OpenFrame GW Configuration File
This section describes the configuration items for OpenFrame GW, and how to configure them.
2.1. ofgw.properties
The following describes each item in the file.
gw.name =gateway_name
datasource.name = datasource_name
lu.port = port_no
lu.autoalloc = {yes|no}
lu.checkStatus = {yes|no}
vtamProperties = {yes|no}
debug.time = {yes|no}
translate.threadPool.core = translate_threadpool_core
translate.threadPool.max = translate_threadpool_max
translate.threadPool.keepAliveTime = translate_threadpool_keepalivetime
db.threadPool.core = db_threadpool_core
db.threadPool.max = db_threadpool_max
db.threadPool.keepAliveTime = db_threadpool_keepalivetime
coroutine.threadPool.core = coroutine_threadpool_core
coroutine.threadPool.max = coroutine_threadpool_max
coroutine.threadPool.keepAliveTime = coroutine_threadpool_keepalivetime
rmi = {yes|no}
rmi.ip = rmi_deployed_ip_address
rmi.port = rmi_port_no
rmi.serviceName = rmi_service_name
rmi.proc = aim_procedure_name
rmi.smqn = aim_smqn_name
rmi.addLength = {yes|no}
rmi.logMessage = {yes|no}
cpmpath = cpmfile_path
terminal.timeout = terminal_timeout
terminal.aliveCheck = {yes|no}
terminal.aliveInterval = terminal_alive_checktime
sslEnabled = {yes|no}
tmax.retrytime = tmax_retrytime
tmax.node.list = node_name_list
tmax.node.NODE1.name = node_name
tmax.node.NODE1.ip = node_ip_address
tmax.node.NODE1.port = node_port_no
tmax.node.NODE1.min = node_min
tmax.node.NODE1.max = node_max
tmax.node.NODE1.rate = node_rate
tmax.node.NODE1.timeout = node_timeput
tmax.node.NODE1.idletime = node_idletime| Item | Description |
|---|---|
gw.name |
Gateway name for the database. |
datasource.name |
DB name specified in the configuration file (domain.xml) in JEUS. |
lu.port |
Port number for 3270 terminal. |
lu.autoalloc |
Option to use VTAM auto allocation function. Set to yes when using RMI server. (Default value: yes) |
lu.checkStatus |
Option to set whether to use the LU Status check function. (Defaultvalue: no) |
vtamProperties |
Option to set VTAM properties including accessible terminals and regions, and initial page display for each port. (Default value: no) |
dhcpProperties |
Option to set whether to use the automatic LU allocation feature with the IP address that maps to the host names listed in dhcp.properties in a DHCP environment. (Default value: no) |
debug.time |
Option to output time log to use for performance check for debugging. |
translate.threadPool.core |
Minimum work thread count. |
translate.threadPool.max |
Maximum work thread count. |
translate.threadPool.keepAlive Time |
Interval for terminating idle threads when the thread count exceeds the specified minimum thread count. (Unit: second) |
db.threadPool.core |
Option to set the minimum number of DB threads. |
db.threadPool.max |
Option to set the maximum number of DB threads. |
db.threadPool.keepAliveTime |
Option to set the time to terminate unused DB threads in idle state when creating more than the minimum number of DB threads. (Unit: second) |
coroutine.threadPool.core |
Option to set the minimum number of Coroutine threads. |
coroutine.threadPool.max |
Option to set the maximum number of Coroutine threads. |
coroutine.threadPool.keepAliveTime |
Option to set the time to terminate unused Coroutine threads in idle state when creating more than the minimum number of Coroutine threads. (Unit: second) |
rmi |
Option to set whether to use RMI server. (Default value: no) |
rmi.ip |
Option to set IP address where the RMI server is located. (Write the same IP address as the OFGW deployed). |
rmi.port |
Option to set the port number to receive data by RMI server. |
rmi.serviceName |
Option to set the service name to receive data by RMI server. |
rmi.proc |
Option to set the procedure of AIM to send data when RMI server communicates with WEBCAM. |
rmi.smqn |
Option to set SMQN of AIM to send data when RMI server communicates with WEBCAM. |
rmi.addLength |
Option to set whether the RMI server communicates with WEBAIM by adding length information on the data to be transmitted. (Default value: no) |
rmi.logMessage |
Option to set whether the RMI server logs the received data and the data to send. When set to yes, change Logger Encoding to SJIS. (Default value: no) |
cpmpath |
Path of the CPM file that is used by the WebTerminal. If not set, the default directory is used. Default value: $OFGW_HOME/ofgwconf/cpm/ |
terminal.timeout |
Timeout to disconnect the idle web terminal that does not communicate with the server. If set to 0, no timeout is used. (Unit: second, Default value: 0) |
terminal.aliveCheck |
Option to set to check the connection status of 3270 emulator and web terminal in OpenFrame GW. When the connection is cut off due to network loss, etc., the terminal resource is automatically released.
|
terminal.aliveInterval |
Option to set the time to check the connection status of terminals connected to OpenFrame GW. (Unit: second, Default value: 10, Minimum number: 10) |
sslEnabled |
Option to enable SSL for communication between OpenFrame GW and 3270 emulator.
|
tmax.retrytime |
Wait time before trying to reconnect after Tmax is disconnected. (Unit: millisecond) |
tmax.node.list |
Tmax node names separated by a comma (,). Example: NODE1,NODE2,NODE3 |
tmax.node.[NODENAME].name |
Tmax node name. |
tmax.node.[NODENAME].ip |
IP of the Tmax node. |
tmax.node.[NODENAME].port |
port ($TMAX_HOST_PORT) of the Tmax node. |
tmax.node.[NODENAME].min |
Minimum number of Tmax connections. |
tmax.node.[NODENAME].max |
Maximum number of Tmax connections. |
tmax.node.[NODENAME].rate |
Number of connections to add when there is insufficient number of connections. |
tmax.node.[NODENAME].timeout |
Waiting time for establishing a connection. (Unit: millisecond) |
tmax.node.[NODENAME].idletime |
Interval for closing idle connections when the number of connections exceeds the minimum count. (Unit: second) |
|
The following shows a sample file.
gw.name = ofgw datasource.name = ds1 lu.port = 5556 lu.autoalloc = yes lu.checkStatus = yes debug.time = no translate.threadPool.core = 5 translate.threadPool.max = 30 translate.threadPool.keepAliveTime = 60 db.threadPool.core = 5 db.threadPool.max = 30 db.threadPool.keepAliveTime = 60 coroutine.threadPool.core = 5 coroutine.threadPool.max = 30 coroutine.threadPool.keepAliveTime = 60 rmi = yes rmi.ip = 192.144.121.11 rmi.port = 5557 rmi.serviceName = ofgwaad rmi.proc = aadproc rmi.smqn = aadsmqn cpmpath = terminal.timeout = 60 sslEnabled = no tmax.node.list = NODE1 tmax.node.NODE1.name = NODE1 tmax.node.NODE1.ip = 192.168.37.11 tmax.node.NODE1.port = 6511 tmax.node.NODE1.min = 5 tmax.node.NODE1.max = 10 tmax.node.NODE1.rate = 2 tmax.node.NODE1.timeout = 20000 tmax.node.NODE1.idletime = 90 tmax.retrytime = 60000
2.2. vtam.properties
Operates when the vtamProperties in ofgw.properties is set to 'yes'.
|
Currently, it supports only in OSC, and does not support in OSI and AIM. |
port.list = port_name
[PORT_NAME].port = port_no
[PORT_NAME].regionList = region_list
[PORT_NAME].initScreen = init_screen_filenameThe following describes each item.
| Item | Description |
|---|---|
port.list |
Port names. Example: PORT1, PORT2, PORT3 |
[PORT_NAME].port |
Port number for PORT_NAME. Must use a port number registered in VTAM. You must set the lu.port specified in ofgw.properties as the port number for one of the PORT_NAME entries. |
[PORT_NAME].regionList |
Region servers that are accessible from a terminal that is connected through the port. Example: OSC00001, OSC00002 |
[PORT_NAME].initScreen |
Initial screen file for this port connection. The file must exist under $OFGW_HOME/ofgwconf/initScreen. |
The following shows a sample file.
port.list = PORT1,PORT2,PORT3 PORT1.port = 5556 PORT1.regionList = OSCOIVP1 PORT1.initScreen = initScreen.txt PORT2.port= 5558 PORT2.regionList = OSCOIVP2 PORT2.initScreen = initScreen2.txt PORT3.port = 5570 PORT3.regionList = OSCOIVP1,OSCOIVP2 PORT3.initScreen = initScreen3.txt
2.3. dhcp.properties
Operates when the dhcpProperties in ofgw.properties is set to 'yes'.
The following describes each item of dhcp.properties.
hostnames = [HOST_NAME1]-[IP1],[HOST_NAME1]-[IP2],[HOST_NAME2]-[IP3],...,\
[HOST_NAME5]-[IP10],...
| Item | Description |
|---|---|
hostnames |
Stores the IP address that maps to the host name entered through the web terminal in a DHCP environment.
|
The following shows a sample file.
hostnames=hostname1-192.168.11.23,hostname2-192.168.14.32,hostname2-192.168.14.33,\ hostname1-192.168.11.31,hostname3-192.168.17.87
How to Use DHCP LU Allocation
Since IP addresses can change dynamically in a DHCP environment, a different method is required to allocate LUs using a fixed IP address. Therefore, OpenFrame GW provides a method to extract a fixed IP based on the host name entered as a query parameter in the web terminal and then use it for LU allocation.
The following is an example of how to allocate LUs in a DHCP environment after setting dhcpProperties to 'yes'.
Using the host name as the key, encode the host name you want to use for LU allocation twice in Base64 (hostname1 → aG9zdG5hbWUx → YUc5emRHNWhiV1V4) and set it as the value. Then, connect the web terminal.
Afterwards, when you try to connect using the conventional method, OpenFrame GW checks that the dhcpProperties is set to 'yes', and retrieves the IP from dhcp.properties using the entered host name (hostname1). Then, it attempts LU allocation using the retrieved IP (192.168.11.23, 192.168.11.31), ignoring the IP of the connected web terminal (127.0.0.1).
|
The LU allocation method using host name operates only when connecting through the web terminal in the manner described above. When connecting via RMI or a 3270 emulator, the existing LU allocation method is used. |
2.4. initScreen.txt
The screen configuration is saved in the initScreen.txt file using a text editor, and is used to display the initial screen when a user logs in to the terminal for the first time with the input cursor following the file output. The screen is displayed exactly as shown in the file.
If vtamProperties is set to 'yes' in ofgw.properties, the file set to [PORT_NAME].initScreen for the specified port in vtam.properties is used to display the initial screen. If the properties file is set to 'no', the initScreen.txt file is used.
@ THIS TERMINAL CONNECTED TO THE OPENFRAME GW
******. *******. ******. **. **.
********. *******. ********. **. **.
**....**. **...... **....**. **. **.
**. **. **. **. ... **. **.
**. **. *******. **. **.**.**.
**. **. *******. **. ****. **.**.**.
**. **. **...... **. ****. **.**.**.
**. **. **. **. .**. ********.
********. **. ********. ***..***.
******.. **. *******. **.. **.
...... .. ....... .. ..
@ ENTER COMMAND :
The following is an example of the initial access screen.
2.5. logback.xml
Defines the file format and the log level of the log file in logback.xml.
The following is an example of the file.
<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="30 seconds">
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<charset>UTF-8</charset>
<pattern>%msg</pattern>
</encoder>
</appender>
<property name="USER_HOME" value="/home/user/logs" />
<appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${USER_HOME}/ofgw-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
<timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
<maxFileSize>300MB</maxFileSize>
</timeBasedFileNamingAndTriggeringPolicy>
<maxHistory>30</maxHistory>
</rollingPolicy>
<encoder>
<pattern>%d{HH:mm:ss.SSS} %-5level %logger{35} - %msg%n</pattern>
</encoder>
</appender>
<logger name="com.tmax.ofgw.region.LUManager" level="DEBUG" />
<logger name="com.tmax.ofgw.Main" level="INFO" />
<logger name="com.tmax.ofgw.region.Region" level="ERROR" />
<logger name="com.tmax.webtnio" level="OFF" />
<root level="DEBUG">
<appender-ref ref="STDOUT" />
<appender-ref ref="ROLLING" />
</root>
</configuration>
The following describes each item in the file.
| Item | Description |
|---|---|
<configuration> |
Scan and scanperiod items can be set to dynamically change the log level. |
<appender> |
Adds the logger format in the form supported by Logback. (Enables logs to be recorded for each event.)
|
<charset> |
Option to set the encoding format of the log file. When rmi.addLength of ofgw.properties is set to 'yes', set the property SJIS. (Default value: UTF-8) |
<property> |
Property value can be used like a variable. USER_HOME in this file is the log file path. |
<fileNamepattern> |
Pattern for the log file name. The default value uses the date format and index, which is specified as "%i". |
<maxFileSize> |
Maximum file size. |
<maxHistory> |
Maximum number of days for storing a log. If the days are exceeded, logs are automatically deleted starting from the oldest date. |
<pattern> |
Log format. |
<logger name> |
Option to set the log level by designating a specific class independently of the log level set in <root>. |
<root> |
Option to set the log level and adds <appender> items to display the log in the specified log level and format. When <logger name> is not specified, the log level of each class is set to the log level written in <root> by default, and in the case of the class in which <logger name> is set, the log level in <root> is overwritten. |
|
These are required items that the user must customize according to the environment. For information about additional items, refer to the logback related guide. |
3. Using OpenFrame GW
This section describes how to start up and shut down OpenFrame GW, and how to output the log format.
3.1. Starting Up and Shutting Down OpenFrame GW
This section describes how to start up and shut down OpenFrame GW.
Startup
If OpenFrame GW is running on JEUS DAS, the <lifecycle-invocation> setting is used to start up OpenFrame GW when DAS starts up. The script that starts up DAS is startDomainAdminServer, and it requires the DAS domain name, and JEUS user name and password. All three values are required if the script is executed under JEUS_HOME/bin, but the domain name can be omitted if it is executed under DOMAIN_HOME of DAS.
The following is the process for starting up OpenFrame GW according to the script path.
-
Start up DAS using startDomainAdminServer.
$JEUS_HOME/bin/startDomainAdminServer -domain <domain_name> -u <user_name> -p <password>
or
$JEUS_HOME/domains/<domain_name>/bin/startDomainAdminServer -u <user_name> -p <password>
-
Start up a Managed Server using startManagedServer.
$JEUS_HOME/domains/<domain_name>/servers/<server_name>/bin/startManagedServer -u <user_name> -p <password>
or
$startManagedServer -domain <domain_name> -server <server_name> -u <user_name> -p <password> -dasurl <das_ip:das_baseport>
-
Use the jps tool to check whether DomainAdminServerBootstrapper and ServerBootstrapper have been started.
$jps 23541 Jps 22797 DomainAdminServerBootstrapper 22981 ServerBootstrapper
Shutdown
Shut down the server on which OpenFrame GW is installed to shut down OpenFrame GW.
-
Shut down a Managed Server using stopServer.
$JEUS_HOME/bin/stopServer -u <user_name> -p <password> -host <server_ip:server_baseport>
-
Shut down DAS using stopServer.
$JEUS_HOME/bin/stopServer -u <user_name> -p <password> -host <server_ip:server_baseport>
To start up or shut down JEUS, use WebAdmin, or use jeusadmin or applicable commands. This guide only describes starting up and shutting down in UNIX. For information about starting up and shutting down using other methods, refer to JEUS Domain Guide or JEUS WebAdmin Guide.
Updating Database at OpenFrame GW Startup and Shutdown
OpenFrame GW updates information in the OFM_BASE_VTAM_GATEWAY andOFM_BASE_VTAM_ACTIVE_LU tables.
When starting up OpenFrame GW, search for any data remaining due to a previous abnormal shut down and update it with the new OpenFrame GW data. When OpenFrame GW shuts down, the terminal connected to the gateway is disconnected, the OpenFrame GW data is deleted from the server, and the terminal data is deleted from the database.
The following describes how to check the OpenFrame GW data by using the vtamadm tool.
-
Check the GATEWAY data
The following describes how to check the gateway data of OpenFrame GW.
$ vtamadm -w VTAM Gateway List ================================================================================= NO. GATEWAY_NAME CLID IP_ADDR:PORT NODENAME --------------------------------------------------------------------------------- 1 ofgw_A 3 192.168.105.208:5668 NODE1 =================================================================================
-
Check the terminal LU data
The following describes how to check the LU data of the terminal connected to OpenFrame GW.
$ vtamadm -l Active LU information connected to VTAM ================================================================================================= NO. LU TYPE CLID NODENAME IP_ADDR LOGON_REGION USERID ------------------------------------------------------------------------------------------------- 1 OSC00001 OSC REGION NODE1 2 OIVPTRM1 IBM-3278-2-E 5 NODE1 192.168.105.208 OSC00001 ROOT 3 TSO TSO NODE1 =================================================================================================
|
vtamadm is a tool provided by OpenFrame. For more information, refer to OpenFrame Tool Reference Guide. |
Starting Up and Shutting Down Online Regions
Starting up or shutting down a region server in OpenFrame does not affect OpenFrame GW operations.
When an online region is started up while OpenFrame GW is running, OpenFrame GW retrieves the region data from the database. When an online region shuts down, the terminal (logged on LU) that was connected to the online region is disconnected and the region data is deleted from the database.
When all OpenFrame engines shut down, all Tmax connections are closed and the following logs are generated.
[2006-04-12T11:28:08.00464] [OFGW|WebtChannelHandlerImpl ] [I] [WebT] close connection for NODE1(clid=1) [2006-04-12T11:28:08.00464] [OFGW|Terminal ] [D] WebTerminal disconnect status=transaction_status_none [2006-04-12T11:28:08.00464] [OFGW|Terminal ] [D] enq DBqueue: id=846990772, data=[DISCONNECT846990772] [2006-04-12T11:28:08.00465] [OFGW|WebtChannelHandlerImpl ] [I] [WebT] system channel NODE1(clid=1) [2006-04-12T11:28:08.00478] [OFGW|LUManager ] [I] terminal(id=846990772) is disconnected
Reconnection attempts are made at the tmax.retrytime interval set in the ofgw.properties file.
3.2. Log Output Format
Logs in logback.xml are outputted in the following format. You can modify the format as needed.
[Time] [Log Level] [Thread] [Logger] [Message]
| Item | Description |
|---|---|
[Time] |
"time:minute:second:millisecond" format. |
[Log Level] |
Specified log level. By default, OpenFrame GW provides four levels of log output: 'ERROR', 'WARN', 'INFO', and 'DEBUG'. The following are the available log levels and description of each log level:
Log levels are defined in the order of ERROR < WARN < INFO < DEBUG. Higher level logs include lower level logs. (e.g: If the log level is set to INFO, logs which level are 'ERROR' and 'WARN' will be also displayed) |
[Thread] |
Current thread name. Expressed as the logging process (server or launcher) and thread number separated by a hyphen (-). |
[Logger] |
'Logger Name + {length}'. Length is the maximum length. |
[Message] |
Log message alias. |
In the following example, the logs are output using the pattern defined in the logback.xml file.
<pattern>%d{HH:mm:ss.SSS} %-5level %logger{35} - %msg%n</pattern>
10:05:54.612 [Thread-19 [server1-101]] DEBUG c.tmax.webtnio.pool.WebtChannelPool - freeList.size() = 3, node.getMin = 5 10:05:54.612 [Thread-19 [server1-101]] DEBUG com.tmax.webtnio.WebtNIOSelector - timeout = 60000, timeout2 = 20000000 10:05:54.612 [Thread-19 [server1-101]] DEBUG com.tmax.webtnio.WebtNIOSelector - lastIdleChkTime = 1121475954612, timeout = 60000 ... 10:05:29.993 [Thread-18 [server1-100]] DEBUG com.tmax.ofgw.io.MainChannelImpl - PipeChannel terminal id : 2118958993 10:05:29.994 [Thread-18 [server1-100]] DEBUG com.tmax.ofgw.io.Tn3270Thread - [WRITEOP] 10:05:29.994 [Thread-18 [server1-100]] DEBUG com.tmax.ofgw.Terminal - get writequeue : 1
4. Multi-Environment Configuration
This section describes how to configure a multi-environment.
4.1. Multi-Node Configuration
To implement a load balancing environment, OpenFrame GW can connect to multiple nodes in an OpenFrame system as shown in the following figure:
To implement a multi-node configuration, configure the ofgw.properties file as shown in the following example. For more information about the file, refer to ofgw.properties. Note that a single OpenFrame GW cannot connect to multiple nodes on different OpenFrame systems.
tmax.node.list = NODE1,NODE2 tmax.node.NODE1.name = NODE1 tmax.node.NODE1.ip = 192.168.33.1 tmax.node.NODE1.port = 6300 tmax.node.NODE1.min = 2 tmax.node.NODE1.max = 6 tmax.node.NODE1.rate = 3 tmax.node.NODE1.timeout = 10000 tmax.node.NODE1.idletime = 30000 tmax.node.NODE2.name = NODE2 tmax.node.NODE2.ip = 192.168.33.1 tmax.node.NODE2.port = 6400 tmax.node.NODE2.min = 2 tmax.node.NODE2.max = 6 tmax.node.NODE2.rate = 3 tmax.node.NODE2.timeout = 10000 tmax.node.NODE2.idletime = 30000 … omitted
Tmax facilitates communication between OpenFrame GW and online regions. Connection scheduling is handled by Tmax and OpenFrame GW is responsible for task scheduling. OpenFrame GW reads the mapping information of each online region from the database and schedules tasks.
4.2. Multi-Gateway Configuration
When multiple OpenFrame GWs are running on a web application server, an OpenFrame GW can run on each server as shown in the following figure:
To implement the previous environment, JEUS server must be configured in domain.xml (${JEUS_HOME}/domains/<domain_name>/config) as in the following example. For descriptions of items in the domain.xml file, refer to JEUS Configuration File. In each directory of the JEUS server, the OpenFrame GW binary must be located in the 'lib/application' directory.
<servers>
<server>
<name>server1</name>
<lifecycle-invocation>
<class-name>com.tmax.ofgw.Main</class-name>
<invocation>
<invocation-method>
<method-name>init</method-name>
</invocation-method>
<invocation-type>READY</invocation-type>
</invocation>
</lifecycle-invocation>
<lifecycle-invocation>
<class-name>com.tmax.ofgw.Main</class-name>
<invocation>
<invocation-method>
<method-name>shutdown</method-name>
</invocation-method>
<invocation-type>BEFORE_UNDEPLOY</invocation-type>
</invocation>
</lifecycle-invocation>
</server>
<server>
<name>server2</name>
<lifecycle-invocation>
<class-name>com.tmax.ofgw.Main</class-name>
<invocation>
<invocation-method>
<method-name>init</method-name>
</invocation-method>
<invocation-type>READY</invocation-type>
</invocation>
</lifecycle-invocation>
<lifecycle-invocation>
<class-name>com.tmax.ofgw.Main</class-name>
<invocation>
<invocation-method>
<method-name>shutdown</method-name>
</invocation-method>
<invocation-type>BEFORE_UNDEPLOY</invocation-type>
</invocation>
</lifecycle-invocation>
</server>
...omitted
</servers>
|
For more information about adding servers, refer to "2.2. Adding a Server" in JEUS Server Guide. |