Sun Java System Application Server Platform Edition 8.1 2005Q2 Update 2 Administration Reference


Defines a virtual server. A virtual server, also called a virtual host, is a virtual web server that serves content targeted for a specific URL. Multiple virtual servers can serve content using the same or different host names, port numbers, or IP addresses. The HTTP service can direct incoming web requests to different virtual servers based on the URL.

When the Application Server is first installed, a default virtual server is created. (You can also assign a default virtual server to each new http-listener you create.)

Note –

Virtual servers are not the same thing as server instances. Each server instance is a completely separate server that contains one or more virtual servers.

Before the Application Server can process a request, it must accept the request via a listener, then direct the request to the correct virtual server. The virtual server is determined as follows:

If a virtual server is configured to an SSL listener, its hosts attribute is checked against the subject pattern of the certificate at server startup, and a warning is generated and written to the server log if they don’t match.




The following table describes subelements for the virtual-server element.

Table 1–129 virtual-server Subelements





zero or more 

Specifies a property or a variable. 


The following table describes attributes for the virtual-server element.

Table 1–130 virtual-server Attributes






Virtual server ID. This is a unique ID that allows lookup of a specific virtual server. A virtual server ID cannot begin with a number. 



(optional) In a comma-separated list, references id attributes of http-listener elements that specify the connection(s) the virtual server uses. Required only for a virtual-server that is not referenced by the default-virtual-server attribute of an http-listener.


system default web module 

(optional) References the name attribute of the default web-module for this virtual server, which responds to requests that cannot be resolved to other web modules deployed to this virtual server (see the application-ref element).



A comma-separated list of values, each of which selects the current virtual server when included in the Host request header. Two or more virtual-server elements that reference or are referenced by the same http-listener cannot have any hosts values in common.



(optional) Determines whether a virtual-server is active (on) or inactive (off, disabled). The default is on (active). When inactive, a virtual-server does not service requests.

If a virtual-server is disabled, only the global server administrator can turn it on.


server.log in the directory specified by the log-root attribute of the domain element

(optional) Writes this virtual server’s log messages to a log file separate from the server log. The file and directory in which the virtual server log is kept must be writable by the user account under which the server runs. See the log-service description for details about logs.


The following table describes properties for the virtual-server element.

Table 1–131 virtual-server Properties






If true, single sign-on is enabled for web applications on this virtual server that are configured for the same realm. If false, single sign-on is disabled for this virtual server, and users must authenticate separately to every application on the virtual server.



Specifies the time after which a user’s single sign-on record becomes eligible for purging if no client activity is received. Since single sign-on applies across several applications on the same virtual server, access to any of the applications keeps the single sign-on record active. Higher values provide longer single sign-on persistence for the users at the expense of more memory use on the server. 



Specifies the interval between purges of expired single sign-on records. 



Specifies a comma-separated list of Cache-Control response directives. For a list of valid directives, see section 14.9 of the document at



Specifies that a request for an old URL is treated as a request for a new URL. These properties are inherited by all web applications deployed on the virtual server. The value of each redirect_n property has two components, which may be specified in any order:

The first component, from, specifies the prefix of the requested URI to match.

The second component, url-prefix, specifies the new URL prefix to return to the client. The from prefix is simply replaced by this URL prefix. For example:

<property name="redirect_1"
value="from=/dummy url-prefix=http://etude"/>