5.2.6 server.xml

The server.xml file contains the main configuration for a WebSphere Application Server instance. It contains configuration information for the communications subsystems underlying the core containers at the Java level (that is, which communications channels are configured, what their maximum number of connections are, what their timeout and buffer sizes are and so on). It also contains more general configuration, such as the JCA and JDBC configuration and user settings that are used to access external resources outside of WebSphere Application Server.

This file is crucial to the environment and presents a security risk if available for reading by anyone other than the WebSphere Application Server administration staff, because the information it contains can be used to access those external resources.

Although server.xml can be directly edited, we advise against this and recommend configuring the configuration beans via wsadmin or by use of the administration system console. The server.xml configuration file examples in this section (Example 5-2 through Example 5-10) were taken from a WebSphere Application Server ND environment configured with clusters inside a cell, on a node called spock44p in the domain RnREnterprise.dyndns.org, which explains some of the names used within the environment.

The identifier for the JVM process within the cell and cluster environment is configured as attributes within the outermost tag; the process:Server tag. As shown in Example 5-2, this tag identifies the XML Metadata Interchange (XMI) files used to apply against the XML files used by this server instance, as well as the instance name and cluster name for that server.

Example 5-2 server.xml: process:Server tag 

<process:Server xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" 
...
xmlns:threadpoolmanager="http://www.ibm.com/websphere/appserver/schemas/6.0/threadpoo
lmanager.xmi" 
...
xmi:id="Server_1172257092257" name="spock44pMember01" clusterName="spock44
pCluster01">

As shown in Example 5-3, within the process:Server tag there are numerous other configuration items, with the configuration of individual WebSphere Application Server services being a major part.

Example 5-3 server.xml: process:Server tag detail 

...
<stateManagement xmi:id="StateManageable_1172257094317" initialState="START"/>
  <statisticsProvider xmi:id="StatisticsProvider_1172257094318" 
specification="com.ibm.orb=enabled"/>
  <services xmi:type="pmiservice:PMIService" xmi:id="PMIService_1172257094318" 
enable="true" initialSpecLevel="" statisticSet="extended" 
synchronizedUpdate="false"/>
...
  <services xmi:type="traceservice:TraceService" xmi:id="TraceService_1172257094319" 
enable="true" startupTraceSpecification="*=info" traceOutputType="SPECIFIED_FILE" 
traceFormat="BASIC" memoryBufferSize="8">
    <traceLog xmi:id="TraceLog_1172257094319" fileName="${SERVER_LOG_ROOT}/trace.log" 
rolloverSize="20" maxNumberOfBackupFiles="1"/>
  </services>
...
  <services xmi:type="loggingservice.ras:RASLoggingService" 
xmi:id="RASLoggingService_1172257094320" enable="true" messageFilterLevel="NONE" 
enableCorrelationId="true">
    <serviceLog xmi:id="ServiceLog_1172257094320" name="${LOG_ROOT}/activity.log" 
size="2" enabled="true"/>
  </services>
...

In Example 5-3, note the use of variables such as ${SERVER_LOG_ROOT} that are mapped from values in the variables.xml file when applied.

One of the most important services to WebSphere Application Server is the orb:ObjectRequestBroker service, shown in Example 5-4. The J2EE standard, particularly with the EJB container, is based on the generic OMG CORBA standard so the ORB configuration is key to EJB behavior. The configuration of this section includes thread pool information, mappings of Java code implementations to interfaces, interceptor configurations for manipulation of the communications and operations chains with the ORB, and any additional plugins that are to be loaded by the environment. Pay particular attention to the com.ibm.ws.orb.transport.UseMultiHome setting that controls whether the EJBs can be remotely accessed over all network interfaces, or just the one named in the com.ibm.CORBA.LocalHost setting.

Example 5-4 server.xml: orb.ObjectRequestBroker detail 

<services xmi:type="orb:ObjectRequestBroker" 
xmi:id="ObjectRequestBroker_1172257094320" enable="true" requestTimeout="180" 
requestRetriesCount="1" requestRetriesDelay="0" connectionCacheMaximum="240" 
connectionCacheMinimum="100" commT
raceEnabled="false" locateRequestTimeout="180" forceTunnel="never" 
noLocalCopies="false" useServerThreadPool="false">
    <properties xmi:id="Property_1172257094321" 
name="com.ibm.CORBA.enableLocateRequest" value="true"/>
...
    <properties xmi:id="Property_1172257094326" 
name="com.ibm.ws.orb.transport.useMultiHome" value="true"/>
    <properties xmi:id="Property_1172257094327" 
name="com.ibm.websphere.management.registerServerIORWithLSD" value="true"/>
    <interceptors xmi:id="Interceptor_1172257094322" 
name="com.ibm.ejs.ras.RasContextSupport"/>
    <interceptors xmi:id="Interceptor_1172257094323" 
name="com.ibm.ws.runtime.workloadcontroller.OrbWorkloadRequestInterceptor"/>
    <interceptors xmi:id="Interceptor_1172257094324" 
name="com.ibm.ws.Transaction.JTS.TxInterceptorInitializer"/>
    <interceptors xmi:id="Interceptor_1172257094325" 
...
    <interceptors xmi:id="Interceptor_1172257094334" 
name="com.ibm.debug.olt.ivbtrjrt.OLT_RI"/>
    <plugins xmi:id="ORBPlugin_1172257094323" 
name="com.ibm.ws.orbimpl.transport.WSTransport"/>
...
    <plugins xmi:id="ORBPlugin_1172257094328" 
name="com.ibm.ws.csi.CORBAORBMethodAccessControl"/>
    <threadPool xmi:id="ThreadPool_1172257094324" minimumSize="10" maximumSize="50" 
inactivityTimeout="3500" isGrowable="false" name="ORB.thread.pool"/>
  </services>

In Example 5-4, also pay attention to the threadPool element configuration because this controls the number of threads used by the ORB for interfacing to the EJB container, which is limited to 50 threads.

Next within the server.xml file is the configuration of the transport channels, shown in Example 5-5, which includes the buffer sizes, which thread pools the threads for servicing them come from, and the chain configuration for layering transports on top of transports (that is, SSL on top of TCP). Note that the channels are split into inbound and outbound channels to better support asynchronous handling of requests and responses within WebSphere Application Server. How this works is explained in the section where we look at the WebSphere Application Server internals and channel configuration. Note that the endPointName attributes refer to settings in serverindex.xml.

Example 5-5 server.xml: transport channel detail 

<services xmi:type="channelservice:TransportChannelService" 
xmi:id="TransportChannelService_1172257094324" enable="true">
    <transportChannels xmi:type="channelservice.channels:TCPInboundChannel" 
xmi:id="TCPInboundChannel_1172257094324" name="TCP_1" endPointName="WC_adminhost" 
maxOpenConnections="20000" inactivityTimeout="60" threadPool="ThreadPool_11722
57094325"/>
    <transportChannels xmi:type="channelservice.channels:TCPInboundChannel" 
xmi:id="TCPInboundChannel_1172257094325" name="TCP_2" endPointName="WC_defaulthost" 
maxOpenConnections="20000" inactivityTimeout="60" threadPool="ThreadPool_117
2257094325"/>
...
    <transportChannels xmi:type="channelservice.channels:TCPInboundChannel" 
xmi:id="TCPInboundChannel_1172257094328" name="TCP_5" 
endPointName="DCS_UNICAST_ADDRESS" maxOpenConnections="20000" inactivityTimeout="60" 
threadPool="ThreadPoo
l_1172257094326"/>
...
    <transportChannels xmi:type="channelservice.channels:SSLInboundChannel" 
xmi:id="SSLInboundChannel_1172257094326" name="SSL_1" discriminationWeight="1"/>
    <transportChannels xmi:type="channelservice.channels:SSLInboundChannel" 
xmi:id="SSLInboundChannel_1172257094327" name="SSL_2" discriminationWeight="1"/>
...
<transportChannels xmi:type="channelservice.channels:HTTPInboundChannel" 
xmi:id="HTTPInboundChannel_1172257094327" name="HTTP_1" discriminationWeight="10" 
maximumPersistentRequests="100" keepAlive="true" readTimeout="60" writeTimeou
t="60" persistentTimeout="30" enableLogging="false"/>
    <transportChannels xmi:type="channelservice.channels:HTTPInboundChannel" 
xmi:id="HTTPInboundChannel_1172257094328" name="HTTP_2" discriminationWeight="10" 
maximumPersistentRequests="100" keepAlive="true" readTimeout="60" writeTimeou
t="60" persistentTimeout="30" enableLogging="false"/>
...
    <transportChannels xmi:type="channelservice.channels:WebContainerInboundChannel" 
xmi:id="WebContainerInboundChannel_1172257094328" name="WCC_1" 
discriminationWeight="1" writeBufferSize="32768"/>
    <transportChannels xmi:type="channelservice.channels:WebContainerInboundChannel" 
xmi:id="WebContainerInboundChannel_1172257094329" name="WCC_2" 
discriminationWeight="1" writeBufferSize="32768"/>
...
    <transportChannels xmi:type="channelservice.channels:DCSInboundChannel" 
xmi:id="DCSInboundChannel_1172257094329" name="DCS_1" discriminationWeight="1"/>
    <transportChannels xmi:type="channelservice.channels:DCSInboundChannel" 
xmi:id="DCSInboundChannel_1172257094330" name="DCS_2" discriminationWeight="1"/>
...
    <transportChannels xmi:type="channelservice.channels:UDPInboundChannel" 
xmi:id="UDPInboundChannel_1172257094340" name="UDP_1" discriminationWeight="0" 
endPointName="SIP_DEFAULTHOST"/>
    <transportChannels xmi:type="channelservice.channels:TCPInboundChannel" 
xmi:id="TCPInboundChannel_1172257094340" name="SIB_TCP_JFAP" 
endPointName="SIB_ENDPOINT_ADDRESS" threadPool="ThreadPool_1172257094341"/>
    <transportChannels xmi:type="channelservice.channels:TCPInboundChannel" 
xmi:id="TCPInboundChannel_1172257094341" name="SIB_TCP_JFAP_SSL" 
endPointName="SIB_ENDPOINT_SECURE_ADDRESS" threadPool="ThreadPool_1172257094341"/>
    <transportChannels xmi:type="channelservice.channels:TCPInboundChannel" 
xmi:id="TCPInboundChannel_1172257094342" name="SIB_TCP_MQFAP" 
endPointName="SIB_MQ_ENDPOINT_ADDRESS" threadPool="ThreadPool_1172257094341"/>
    <transportChannels xmi:type="channelservice.channels:TCPInboundChannel" 
xmi:id="TCPInboundChannel_1172257094343" name="SIB_TCP_MQFAP_SSL" 
endPointName="SIB_MQ_ENDPOINT_SECURE_ADDRESS" threadPool="ThreadPool_1172257094341"/>
...
<transportChannels xmi:type="channelservice.channels:TCPOutboundChannel" 
xmi:id="TCPOutboundChannel_1172257094343" name="SIB_TCP_JFAP_SSL_OUT" 
inactivityTimeout="60" threadPool="ThreadPool_1172257094342"/>
    <transportChannels xmi:type="channelservice.channels:TCPOutboundChannel" 
xmi:id="TCPOutboundChannel_1172257094344" name="SIB_TCP_JFAP_TUN_OUT" 
inactivityTimeout="60" threadPool="ThreadPool_1172257094342"/>
...
<transportChannels xmi:type="channelservice.channels:HTTPOutboundChannel" 
xmi:id="HTTPOutboundChannel_1172257094344" name="SIB_HTTP_JFAP_TUN_OUT"/>
    <transportChannels xmi:type="channelservice.channels:HTTPOutboundChannel" 
xmi:id="HTTPOutboundChannel_1172257094345" name="SIB_HTTP_JFAP_TUN_SSL_OUT"/>
    <transportChannels xmi:type="channelservice.channels:HTTPTunnelOutboundChannel" 
...
    <chains xmi:id="Chain_1172257094346" name="WCInboundAdmin" enable="true" 
transportChannels="TCPInboundChannel_1172257094324 HTTPInboundChannel_1172257094327 
WebContainerInboundChannel_1172257094328"/>
    <chains xmi:id="Chain_1172257094360" name="WCInboundDefault" enable="true" 
transportChannels="TCPInboundChannel_1172257094325 HTTPInboundChannel_1172257094328 
WebContainerInboundChannel_1172257094329"/>
...
<chains xmi:id="Chain_1172257094363" name="DCS" enable="true" 
transportChannels="TCPInboundChannel_1172257094328 DCSInboundChannel_1172257094329"/>
    <chains xmi:id="Chain_1172257094364" name="DCS-Secure" enable="true" 
transportChannels="TCPInboundChannel_1172257094328 SSLInboundChannel_1172257094328 
DCSInboundChannel_1172257094330"/>
    <chains xmi:id="Chain_1172257094365" name="SIPCInboundDefault" enable="true" 
transportChannels="TCPInboundChannel_1172257094329 SIPInboundChannel_1172257094329 
SIPContainerInboundChannel_1172257094340"/>
    <chains xmi:id="Chain_1172257094366" name="SIPCInboundDefaultSecure" 
enable="true" transportChannels="TCPInboundChannel_1172257094330 
SSLInboundChannel_1172257094329 SIPInboundChannel_1172257094330 
SIPContainerInboundChannel_1172257
094341"/>
    <chains xmi:id="Chain_1172257094367" name="SIPCInboundDefaultUDP" enable="true" 
transportChannels="UDPInboundChannel_1172257094340 SIPInboundChannel_1172257094331 
SIPContainerInboundChannel_1172257094342"/>
    <chains xmi:id="Chain_1172257094368" name="InboundBasicMessaging" enable="true" 
transportChannels="TCPInboundChannel_1172257094340 
JFAPInboundChannel_1172257094342"/>
    <chains xmi:id="Chain_1172257094369" name="InboundSecureMessaging" enable="true" 
transportChannels="TCPInboundChannel_1172257094341 SSLInboundChannel_1172257094341 
JFAPInboundChannel_1172257094343"/>
...
    <chains xmi:id="Chain_1172257094372" name="BootstrapBasicMessaging" 
transportChannels="JFAPOutboundChannel_1172257094345 
TCPOutboundChannel_1172257094342"/>
    <chains xmi:id="Chain_1172257094373" name="BootstrapSecureMessaging" 
transportChannels="JFAPOutboundChannel_1172257094346 SSLOutboundChannel_1172257094345 
TCPOutboundChannel_1172257094343"/>
    <chains xmi:id="Chain_1172257094374" name="BootstrapTunneledMessaging" 
transportChannels="JFAPOutboundChannel_1172257094347 
HTTPTunnelOutboundChannel_1172257094344 HTTPOutboundChannel_1172257094344 
TCPOutboundChannel_1172257094344"/
>
    <chains xmi:id="Chain_1172257094375" name="BootstrapTunneledSecureMessaging" 
transportChannels="JFAPOutboundChannel_1172257094348 
HTTPTunnelOutboundChannel_1172257094345 HTTPOutboundChannel_1172257094345 
SSLOutboundChannel_117225709
4346 TCPOutboundChannel_1172257094345"/>
...

One of the most important configuration elements at the service level within the appserver is the threadpoolmanager:ThreadPoolManager configuration that controls the sizes and management of thread pools for the different containers and components within WebSphere Application Server, as shown in Example 5-6. Note that the largest size that the thread pools can reach is 50 threads and that these are not "growable". Very careful consideration must be taken with modifying these values directly, because arrays are used in some of the thread pool management code for performance and going above the array size will cause failure.

Example 5-6 server.xml: threadpoolmanager detail 

<services xmi:type="threadpoolmanager:ThreadPoolManager" 
xmi:id="ThreadPoolManager_1172257094364" enable="true">
    <threadPools xmi:id="ThreadPool_1172257094364" minimumSize="10" maximumSize="50" 
inactivityTimeout="3500" isGrowable="false" name="ORB.thread.pool"/>
    <threadPools xmi:id="ThreadPool_1172257094365" minimumSize="1" maximumSize="3" 
inactivityTimeout="30000" isGrowable="false" name="server.startup" description="This 
pool is used by WebSphere during server startup."/>
    <threadPools xmi:id="ThreadPool_1172257094366" minimumSize="5" maximumSize="20" 
name="Default"/>
    <threadPools xmi:id="ThreadPool_1172257094325" minimumSize="10" maximumSize="50" 
inactivityTimeout="3500" isGrowable="false" name="WebContainer"/>
    <threadPools xmi:id="ThreadPool_1172257094326" minimumSize="5" maximumSize="20" 
name="TCPChannel.DCS"/>
    <threadPools xmi:id="ThreadPool_1172257094341" minimumSize="4" maximumSize="50" 
name="SIBFAPInboundThreadPool" description="Service integration bus FAP inbound 
channel thread pool"/>
    <threadPools xmi:id="ThreadPool_1172257094342" minimumSize="4" maximumSize="50" 
name="SIBFAPThreadPool" description="Service integration bus FAP outbound channel 
thread pool"/>
  </services>

The next part of the file includes the names of HTTP logging files and whether HTTP logging is to be enabled, as shown in Example 5-7. Again, note the mapping of variable names from variables.xml.

Example 5-7 server.xml: logging detail 

<services xmi:type="loggingservice.http:HTTPAccessLoggingService" 
xmi:id="HTTPAccessLoggingService_1172257094365" enable="false" 
enableErrorLogging="true" enableAccessLogging="true">
    <errorLog xmi:id="LogFile_1172257094365" 
filePath="${SERVER_LOG_ROOT}/http_error.log" maximumSize="500"/>
    <accessLog xmi:id="LogFile_1172257094366" 
filePath="${SERVER_LOG_ROOT}/http_access.log" maximumSize="500"/>
  </services>

After the services section of the server.xml file, a number of different configuration items are used as shown in Example 5-8. A small section identifies the redirection of the system standard input and standard output files for the process. The rollover control settings for log file cycling and management and the stack trace settings are important for management of size, cycling, and retention of log files at the AIX level, so the AIX administrator should be aware of these settings and manage the external AIX environment accordingly.

Example 5-8 server.xml: StreamRedirect detail 

<errorStreamRedirect xmi:id="StreamRedirect_1172257094366" 
fileName="${SERVER_LOG_ROOT}/SystemErr.log" rolloverType="SIZE" 
maxNumberOfBackupFiles="1" rolloverSize="1" baseHour="24" rolloverPeriod="24" 
formatWrites="true" messageFormat
Kind="BASIC" suppressWrites="false" suppressStackTrace="false"/>
<outputStreamRedirect xmi:id="StreamRedirect_1172257094367" 
fileName="${SERVER_LOG_ROOT}/SystemOut.log" rolloverType="SIZE" 
maxNumberOfBackupFiles="1" rolloverSize="1" baseHour="24" rolloverPeriod="24" 
formatWrites="true" messageForma
tKind="BASIC" suppressWrites="false" suppressStackTrace="false"/>

The next important section is the components section, which controls the individual components of WebSphere Application Server and how they behave with separate entries for each core component (that is, the Web container, the core appserver, the EJB container, and so on), as shown in Example 5-9. These entries include configuration to enable and control individual containers and what components are loaded within them, including thread pool management configuration and mapping of listeners to the containers, giving us component and service configuration within higher level component configuration.

Note that the appserver component has the Web container and EJB container components configured within it. This information will be important later when the internals of the runtime plugin.xml file and how the appserver starts up are considered.

The information here affects the memory used by the appserver; that is, the number of sessions to be maintained, and how I/O is handled by the given component. User ID and password information for the session persistence database are also configured here, so this file must be carefully secured if this information is sensitive for a particular environment.

Example 5-9 server.xml: components section detail 

<components xmi:type="namingserver:NameServer" xmi:id="NameServer_1172257094366">
    <stateManagement xmi:id="StateManageable_1172257094367" initialState="START"/>
  </components>
  <components xmi:type="applicationserver:ApplicationServer" 
xmi:id="ApplicationServer_1172257094367" applicationClassLoaderPolicy="MULTIPLE">
    <stateManagement xmi:id="StateManageable_1172257094368" initialState="START"/>
    <services xmi:type="applicationserver:TransactionService" 
xmi:id="TransactionService_1172257094367" enable="true" 
totalTranLifetimeTimeout="120" clientInactivityTimeout="60" 
propogatedOrBMTTranLifetimeTimeout="300" httpProxyPrefix="
" httpsProxyPrefix=""/>
    <services xmi:type="applicationserver:DynamicCache" 
xmi:id="DynamicCache_1172257094368" enable="true">
      <cacheGroups xmi:id="ExternalCacheGroup_1172257094368" name="EsiInvalidator">
        <members xmi:id="ExternalCacheGroupMember_1172257094368" address="localhost" 
adapterBeanName="com.ibm.websphere.servlet.cache.ESIInvalidatorServlet"/>
      </cacheGroups>
    </services>
    <components xmi:type="applicationserver.webcontainer:WebContainer" 
xmi:id="WebContainer_1172257094368" enableServletCaching="false" 
disablePooling="false">
      <stateManagement xmi:id="StateManageable_1172257094369" initialState="START"/>
      <services xmi:type="applicationserver.webcontainer:SessionManager" 
xmi:id="SessionManager_1172257094369" enable="true" enableUrlRewriting="false" 
enableCookies="true" enableSSLTracking="false" enableProtocolSwitchRewriting="false"
 sessionPersistenceMode="DATA_REPLICATION" enableSecurityIntegration="false" 
allowSerializedSessionAccess="false" maxWaitTime="5" accessSessionOnTimeout="true">
        <defaultCookieSettings xmi:id="Cookie_1172257094369" domain="" 
maximumAge="-1" secure="false"/>
        <sessionDatabasePersistence xmi:id="SessionDatabasePersistence_1172257094369" 
datasourceJNDIName="jdbc/Sessions" userId="db2admin" password="{xor}Oz1tPjsyNjE=" 
db2RowSize="ROW_SIZE_4KB" tableSpaceName=""/>
        <tuningParams xmi:id="TuningParams_1172257094384" usingMultiRowSchema="false" 
maxInMemorySessionCount="1000" allowOverflow="true" scheduleInvalidation="false" 
writeFrequency="TIME_BASED_WRITE" writeInterval="10" writeContents="O
NLY_UPDATED_ATTRIBUTES" invalidationTimeout="30">
          <invalidationSchedule xmi:id="InvalidationSchedule_1172257094384" 
firstHour="14" secondHour="2"/>
        </tuningParams>
        <sessionDRSPersistence xmi:id="DRSSettings_1172257095445" 
messageBrokerDomainName="spock44pCluster01"/>
      </services>
    </components>
    <components xmi:type="applicationserver.ejbcontainer:EJBContainer" 
xmi:id="EJBContainer_1172257094384" passivationDirectory="${USER_INSTALL_ROOT}/temp" 
inactivePoolCleanupInterval="30000">
      <stateManagement xmi:id="StateManageable_1172257094385" initialState="START"/>
      <services 
xmi:type="applicationserver.ejbcontainer.messagelistener:MessageListenerService" 
xmi:id="MessageListenerService_1172257094385">
        <threadPool xmi:id="ThreadPool_1172257094385" minimumSize="10" 
maximumSize="50" inactivityTimeout="3500" isGrowable="false" 
name="Message.Listener.Pool"/>
      </services>
      <cacheSettings xmi:id="EJBCache_1172257094385" cleanupInterval="3000" 
cacheSize="2053"/>
      <timerSettings xmi:id="EJBTimer_1172257094385" 
datasourceJNDIName="jdbc/DefaultEJBTimerDataSource" tablePrefix="EJBTIMER_" 
pollInterval="300" numAlarmThreads="1"/>
    </components>
    <components xmi:type="portletcontainer:PortletContainer" 
xmi:id="PortletContainer_1172257094386"/>
    <components xmi:type="applicationserver.sipcontainer:SIPContainer" 
xmi:id="SIPContainer_1172257094386" name="" maxAppSessions="120000" 
maxMessageRate="5000" maxDispatchQueueSize="3200" maxResponseTime="0" 
statAveragePeriod="1000" st
atUpdateRange="10000"/>
    <webserverPluginSettings xmi:id="WebserverPluginSettings_1172257094386" 
WaitForContinue="false" ConnectTimeout="0" MaxConnections="-1" 
ExtendedHandshake="false" ServerIOTimeout="0"/>
  </components>

For the Web container configuration, notice the session persistence configuration that controls the underlying web container clustering management of session state, and the sessionPersistanceMode of DATA_REPLICATION for availability of session data between cluster members. The cluster name is mentioned with the sessionDRSPersistence element and messageBrokerDomainName attribute to show that the Data Replication Service uses this domain name with the Reliable Multicast Messaging (RMM) protocol to share session data within the configured cluster.

The final part of the server.xml file controls the configuration items for the JVM and its command line as shown in Example 5-10, including extra arguments (such as the SPNEGO entry here for use of Kerberos and the SPNEGO TAI for single signon), and files to redirect native standard input and standard output to. The runAsUser and runAsGroup and priority information configured here gets mapped to the underlying platform (in this case, AIX).

Example 5-10 server.xml: JVM configuration detail 

<processDefinitions xmi:type="processexec:JavaProcessDef" 
xmi:id="JavaProcessDef_1172257094386" workingDirectory="${USER_INSTALL_ROOT}" 
executableTargetKind="JAVA_CLASS" executableTarget="com.ibm.ws.runtime.WsServer">
    <execution xmi:id="ProcessExecution_1172257094387" processPriority="20" 
runAsUser="" runAsGroup=""/>
    <ioRedirect xmi:id="OutputRedirect_1172257094387" 
stdoutFilename="${SERVER_LOG_ROOT}/native_stdout.log" 
stderrFilename="${SERVER_LOG_ROOT}/native_stderr.log"/>
    <monitoringPolicy xmi:id="MonitoringPolicy_1172257094387" 
maximumStartupAttempts="3" pingInterval="60" pingTimeout="300" autoRestart="true" 
nodeRestartState="STOPPED"/>
    <jvmEntries xmi:id="JavaVirtualMachine_1172257094400" verboseModeClass="false" 
verboseModeGarbageCollection="false" verboseModeJNI="false" runHProf="false" 
debugMode="false" debugArgs="-Djava.compiler=NONE -Xdebug -Xnoagent -Xrunjdw
p:transport=dt_socket,server=y,suspend=n,address=7777" 
genericJvmArguments="-Dcom.ibm.ws.security.spnego.isEnabled=true" 
disableJIT="false"/>
  </processDefinitions>