- 5.1 The magnus.conf File
- 5.2 The server.xml File
- 5.3 The obj.conf File
- 5.4 The mime.types File
- 5.5 Trust Database Files (*.db Files)
- 5.6 The server.policy File
- 5.7 The certmap.conf File
- 5.8 The default.acl File
- 5.9 The default-web.xml File
- 5.10 The login.conf File
- 5.11 The keyfile File
- 5.12 Summary
- 5.13 Self-Paced Labs
This chapter is from the book
This chapter is from the book
This chapter is from the book
5.2 The server.xml File
The server.xml file is the main configuration file for a Web Server instance. It contains initial values for listen sockets, virtual servers, and other components that were configured during the installation process. It also contains several default settings that allow the Web Server to work immediately after installation. You can modify the values for these settings through the Administration Console or the command line interface, or by editing the server.xml file on a particular Administration Node.
5.2.1 Syntax
As the name indicates, the server.xml file contains information in an extensible markup language (XML) format. As such, an understanding of basic XML structure and terminology is essential to understanding the server.xml file.
An XML document contains a hierarchy of elements and values. An element is a unit of XML data and is the basic building block of an XML document. Elements can have associated with them either values or other subelements; thus forming a parent/child relationship.
Elements are delimited by opening and closing tags that have a structure similar to what you might see if you viewed the source of an HTML document (they use the < and > brackets). Elements begin with an opening tag, for example <virtual-server>, and end with the closing tag, for example </virtual-server>. The tags are case-sensitive.
An example of the platform element for a Web Server running in 64-bit mode is as follows:
<platform>64</platform>
An XML document must contain a single root element, which is the topmost element of the hierarchy. Like any other XML element, the root element can contain subelements. The <server> element is the root element of the server.xml file. The <server> element has many subelements, many of which have subelements of their own.
Example 5.2 demonstrates the server.xml file for the default Administration Node.
Example 5.2. Sample server.xml File
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright 2006 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
-->
<server>
<cluster>
<local-host>boulder.example.com</local-host>
<instance>
<host>boulder.example.com</host>
</instance>
</cluster>
<log>
<log-file>../logs/errors</log-file>
<log-level>info</log-level>
</log>
<platform>64</platform>
<temp-path>/tmp/https-boulder.example.com-6accbd0a</temp-path>
<user>webservd</user>
<jvm>
<java-home>/sun/webserver7/jdk</java-home>
<server-class-path>
/sun/webserver7/lib/webserv-rt.jar:/sun/webserver7/lib/pwc.jar:
/sun/webserver7/lib/ant.jar:${java.home}/lib/tools.jar:
/sun/webserver7/lib/ktsearch.jar:/sun/webserver7/lib/webserv-jstl.jar:
/sun/webserver7/lib/jsf-impl.jar:/sun/webserver7/lib/jsf-api.jar:
/sun/webserver7/lib/webserv-jwsdp.jar:/sun/webserver7/lib/
container-auth.jar:
/sun/webserver7/lib/mail.jar:/sun/webserver7/lib/activation.jar
</server-class-path>
<debug>false</debug>
<debug-jvm-options>
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7896
</debug-jvm-options>
<jvm-options>-Djava.security.auth.login.config=login.conf
</jvm-options>
<jvm-options>-Xms128m -Xmx256m</jvm-options>
</jvm>
<thread-pool>
<max-threads>128</max-threads>
<stack-size>131072</stack-size>
</thread-pool>
<default-auth-db-name>keyfile</default-auth-db-name>
<auth-db>
<name>keyfile</name>
<url>file</url>
<property>
<name>syntax</name>
<value>keyfile</value>
</property>
<property>
<name>keyfile</name>
<value>keyfile</value>
</property>
</auth-db>
<acl-file>default.acl</acl-file>
<mime-file>mime.types</mime-file>
<access-log>
<file>../logs/access</file>
</access-log>
<http-listener>
<name>http-listener-1</name>
<port>80</port>
<server-name>boulder.example.com</server-name>
<default-virtual-server-name>boulder.example.com</default-
virtual-server-name>
</http-listener>
<virtual-server>
<name>boulder.example.com</name>
<host>boulder.example.com</host>
<http-listener-name>http-listener-1</http-listener-name>
<document-root>/sun/webserver7/https-boulder.example.com/docs
</document-root>
</virtual-server>
</server>
If a given variable name is defined at both the <virtual-server> and <server> levels, the <virtual-server> value takes precedence.
5.2.2 XML Schema
An XML schema provides a means for defining the structure, content, and semantics of XML documents. It can specify the constraints (that is, valid element names, data types, and values) on XML documents, using an XML-based language. An XML schema is hierarchical, so it is easier to create an unambiguous specification, and it’s possible to determine the scope over which a comment is meant to apply.
Web Server 7.0 validates the format and content of the server.xml against the sun-web-server_7_0.xsd schema. This file can be found in the lib/dtds subdirectory; directly beneath the Web Server 7.0 installation directory. An understanding of this file will help you understand valid element names and the structure of those elements as they are found in the server.xml file.
For example, the following definition provides the structure for the <user> element:
<xs:element name="user" type="userType" minOccurs="0"
maxOccurs="1"/>
The userType attribute describes the format of the data (such as the minimum length) and can also be found in the schema file. The <user> element is optional in the file because the minOccurs value is set to 0. If this element appears in the server.xml file, however, the maximum number of times it can occur is once (as specified by the maxOccurs value).
5.2.3 Context
Each instance can contain only one server.xml file; therefore, there is a one-to-one correspondence between an instance and the server.xml file. The server.xml file contains definitions for each virtual server contained within the instance, so there is a one-to-many relationship between the server.xml file and virtual servers.
5.2.4 Modifications
Some changes made through the Administration Console or the command line interface update the server.xml file. If this file is updated as a result of changes made through either of these two interfaces, you must deploy the updated configuration before the changes are reflected on the appropriate Administration Node(s).
The server.xml file is validated against the sun-web-server_7_0.xsd schema when you start or dynamically reconfigure the instance. Errors found at that time prevent the server from starting properly. You can use the -configtest option to the startserv script to validate the server.xml file before you stop the server. This enables you to detect errors to the file without impacting a running server instance.