This chapter includes the following sections:
A server template contains common, non-default settings and attributes that you can apply to a set of server instances, which then inherit the template configuration. You can define server-specific values for server instances that require unique attributes by overriding the server template in the server instance definition. At runtime, the domain merges the attributes configured in the server template with any server-specific overrides so that all attributes are defined for all server instances.
Example 5-1 shows an example config.xml file that uses a server template. In this example, common configuration is defined in the <server-template> element. The individual server definitions set server-specific attributes (name, listen-port) and specify the server template upon which to base additional configuration (my-cluster-server-template).
Example 5-1 Example config.xml File Using a Server Template
<server>
<name>my-server-1</name>
<listen-port>7010</listen-port>
<server-template>my-cluster-server-template</server-template>
</server>
<server>
<name>my-server-2</name>
<listen-port>7020</listen-port>
<server-template>my-cluster-server-template</server-template>
</server>
<server-template>
<name>my-cluster-server-template</name>
<accept-backlog>2000</accept-backlog>
<cluster>my-cluster</cluster>
<restart-max>10</restart-max>
<reverse-dns-allowed>true</reverse-dns-allowed>
<startup-timeout>600</startup-timeout>
</server-template>
Server templates enable you to easily manage configuration for a group of server instances in one centralized location. You can define common configuration attributes in a server template and then apply the template to other server instances without having to manually configure each one. If you need to define any server-specific attributes, you can easily override the server template at the individual server level.
If you need to update an attribute across all server instances, you can simply change the value in the server template and the new value takes effect in all of the server instances that use that server template. You do not need to write a WLST script to update all the servers in the domain.
Server templates also help with performance and startup time. Defining common attributes once in the server template, instead of setting the same attribute in each server instance definition, reduces the size of the config.xml file.
You also use server templates to create dynamic clusters. For more information, see "Dynamic Clusters" in Administering Clusters for Oracle WebLogic Server.
You create server templates using WebLogic Scripting Tool (WLST) or the WebLogic Server Administration Console. Example 5-2 demonstrates using WLST. For information about using the WebLogic Server Administration Console, see "Create server templates" in the Oracle WebLogic Server Administration Console Online Help. To configure server templates, you can use any of the administration tools listed in "Summary of System Administration Tools and APIs" in Understanding Oracle WebLogic Server.
If needed, you can define server-specific attributes or override any server template value directly in the individual server definition. For example, some server-specific attributes, such as Notes, ConsensusProcessIdentifier, InterfaceAddress, and so on, are more useful when defined at the individual server level.
A server template contains different types of attributes, including primitive datatypes, singleton elements, and arrays of configuration elements. To override a server template value, you define the attribute in the individual server definition.
WebLogic Server determines which attribute value to use based on the following override hierarchy:
If you do not define an attribute in the individual server configuration or in the server template, then the default value is used.
If you define an attribute in the server template, then the server template overrides the default value. The server template value is used.
If you define an attribute in the individual server configuration, then the server configuration overrides the server template value and the default value. The individual server configuration value is used.
Note:
Once you override a value in the individual server configuration, this value always takes precedence over the value in the server template. To remove the overridden value and use the value in the server template, use the unSet attribute command.
At runtime, the domain merges the attributes defined in the server template and individual server definitions to return the desired configuration.
A server instance can override attributes from a server template, but the overrides for each type of attribute differ. For primitive datatypes, the server configuration value overrides the value in the server template. For example, if the server template defines the listen port to be 7101, but you set an explicit listen port value in the server configuration, the server instance value overrides the server template listen port value.
A server instance also overrides values for attributes contained within a child singleton element. For example, if the server template defines a common root directory value in the <server-start> child element, but you set an explicit root directory value in the <server-start> element in the server configuration, the server instance overrides the server template root directory value.
For child array configuration elements, the server instance cannot override individual child elements or attributes within a child element within an array. The server configuration can only override the entire array of configuration elements. For example, if a server template defines an array of NetworkAccessPoint elements, and the server instance configuration defines an array of NetworkAccessPoints, the server instance NetworkAccessPoints override the values in the server template.
The following example demonstrates overriding NetworkAccessPoints in a server instance by using WLST, and includes inline comments.
#
#A server template named Cluster Template defines a NetworkAccessPoint named
#AccessPoint-1. The server instance s1 references Cluster Template as its
#template. A ls() command on s1 shows the following:
#
wls:/mydomain/edit/Servers/s1/NetworkAccessPoints !> ls
drw- AccessPoint-1
#
#Server instance s1 then defines a NetworkAccessPoint at the server instance
#level.
#
wls:/mydomain/edit/Servers/s1 !>
cmo.createNetworkAccessPoint("AccessPoint-2")
#
#This results in an override of the NetworkAccessPoints from the Cluster Template.
#AccessPoint-1 is no longer present in s1 and only AccessPoint-2 is defined in s1.
#
wls:/mydomain/edit/Servers/s1/NetworkAccessPoints !> ls
drw- AccessPoint-2
Server templates contain common attributes and provide the same values for each server instance that inherits configuration from the template. In some cases, you may want to define a standard value for an attribute, but the value must be slightly different for each server instance. You can define the server-specific attribute value in each server instance, but if the attribute follows a pattern, you may be able to use a macro.
You can define a macro for any string attribute in a server template. Macros are case sensitive and cannot be used for integers or references to other configuration elements. The valid macros available for use in server templates are:
${id}: Instance ID of the dynamically created server; this ID starts at 1.
${serverName}: The name of the server to which this element belongs.
${clusterName}: The name of the cluster to which this element belongs. If this element does not belong to a cluster, then an empty string is substituted.
${domainName}: The name of the domain to which this element belongs.
${system-property-name}: If this is not one of the predefined macro names listed previously, then it is evaluated as a system property, and the value is returned. If the system property does not exist, then an empty string is substituted.
Example 5-2 demonstrates using WLST to create two server instances that use the same server template. The example includes inline comments and describes how to:
Create a server template and name it my-cluster-server-template.
Set all of the common attributes in my-cluster-server-template.
Create server instances my-server1 and my-server2, and assign the my-cluster-server-template to each one.
Set server-specific attributes.
Example 5-2 Using Server Templates with WLST
#
# This example demonstrates the WLST commands needed to create a server template
# (my-cluster-server-template) and server instances (my-server-1, my-server-2)
# that use the server template. The creation of the cluster (my-cluster) and
# machines (PrimaryMachine, SecondaryMachine) are not included in this example;
# they must be created before running this script. To keep this example
# simple, error handling was omitted.
#
connect()
edit()
startEdit()
#
# Create the server template and set the common attributes that are used in all
# servers. Attributes such as Accept Backlog, Auto Restart, etc. are the same
# across all cluster members.
#
serverTemplate=cmo.createServerTemplate("my-cluster-server-template")
serverTemplate.setAcceptBacklog(2000)
serverTemplate.setAutoRestart(true)
serverTemplate.setRestartMax(10)
serverTemplate.setReverseDNSAllowed(true)
serverTemplate.setStagingMode("external_stage")
serverTemplate.setStartupTimeout(600)
myCluster=cmo.lookupCluster("my-cluster")
serverTemplate.setCluster(myCluster)
#
# Create the individual server instances, set the server specific attributes, and
# set the template so the server uses the common attributes from the template.
# Attributes such as cluster weight, listen port, and machine are server-specific
# so they are not included in the server template.
#
server1=cmo.createServer("my-server-1")
server1.setClusterWeight(70)
server1.setListenPort(7010)
primary=cmo.lookupMachine("PrimaryMachine")
server1.setMachine(primary)
server1.setServerTemplate(serverTemplate)
#
server2=cmo.createServer("my-server-2")
server2.setClusterWeight(90)
server2.setListenPort(7020)
secondary=cmo.lookupMachine("SecondaryMachine")
server2.setMachine(secondary)
server2.setServerTemplate(serverTemplate)
#
# activate the changes
#
activate()
The resulting config.xml file is:
<server>
<name>my-server-1</name>
<cluster-weight>70</cluster-weight>
<listen-port>7010</listen-port>
<machine>PrimaryMachine</machine>
<server-template>my-cluster-server-template</server-template>
</server>
<server>
<name>my-server-2</name>
<cluster-weight>90</cluster-weight>
<listen-port>7020</listen-port>
<machine>SecondaryMachine</machine>
<server-template>my-cluster-server-template</server-template>
</server>
<server-template>
<name>my-cluster-server-template</name>
<accept-backlog>2000</accept-backlog>
<auto-restart>true</auto-restart>
<cluster>my-cluster</cluster>
<restart-max>10</restart-max>
<reverse-dns-allowed>true</reverse-dns-allowed>
<staging-mode>external_stage</staging-mode>
<startup-timeout>600</startup-timeout>
</server-template>