Use the wsadmin tool to extract a properties file from
one cell, modify environment-specific variables at the bottom of the
extracted properties file, and then apply the modified properties
file to another cell. Modifying environment-specific variables makes
a properties file portable.
Before you begin
If the properties file that you want to edit was created
before Version 7.0.0.7 of the product, examine the properties file
and see whether it contains an XMI id such as the following:
#
# SubSection 1.0 # Virtual Hosts
#
ResourceType=VirtualHost
ImplementingResourceType=VirtualHost
ResourceId=Cell=!{cellName}:VirtualHost=ID#VirtualHost_1
#
#Properties
#
name=default_host
EnvironmentVariablesSection
#Environment Variables
cellName=myNode04Cell
An XMI id is a unique identifier that a product
previous to Version 7.0.0.7 generates when creating a configuration
object. An XMI id can be different in another environment for the
same object. In this example, a VirtualHost resource for default host
in one environment has an XMI id of VirtualHost_1.
In another environment, the XMI id might be a different value, such
as VirtualHost_2. Properties files that have XMI
identifiers are not portable. You cannot apply extracted properties
that have XMI identifiers to another environment without first modifying
the resource identifiers.
The same virtual host section in a
properties file that has portable resource identifiers resembles the
following:
#
# SubSection 1.0 # Virtual Hosts
#
ResourceType=VirtualHost
ImplementingResourceType=VirtualHost
ResourceId=Cell=!{cellName}:VirtualHost=default_host
#
#Properties
#
name=default_host
EnvironmentVariablesSection
#Environment Variables
cellName=myNode04Cell
In this example, name is
used as a key attribute to identify the VirtualHost object uniquely
within an environment. An object can have more than one key attribute
to uniquely identify it among different instances of the same type.
About this task
You can apply properties files that have portable resource
identifiers to another environment.
To extract a properties
file so that it has portable resource identifiers, use the extractConfigProperties
command with the PortablePropertiesFile option set to true.
Properties files extracted with this option are portable. The extracted
properties files do not identify each resource uniquely. A resource
identifier might have one or more attribute name and value pairs;
for example, a nodeName attribute identifies a node
and a serverName attribute identifies a server.
By
default, an extracted properties file is not portable. But a properties
file extracted with the PortablePropertiesFile option set to true is
portable.
After you extract a properties file with the PortablePropertiesFile
option set to true, change the EnvironmentVariablesSection
at the bottom of the properties file, copy the properties files to
the target environment, and then run the applyConfigProperties command
to apply the properties file to another cell.
You can also use
interactive mode with these commands, as the following syntax demonstrates:
AdminTask.command_name('-interactive')
- Start the wsadmin scripting tool.
To start
wsadmin using the Jython language, run the following command from
the
bin directory of the server profile:
wsadmin -lang Jython
- Extract a properties file using the extractConfigProperties
command with the PortablePropertiesFile option set to true.
For example, to extract properties of a server named server1 to
the server.props file in a portable format, run
following wsadmin command:
AdminTask.extractConfigProperties('[-propertiesFileName server.props -configData Server=server1
-options [[PortablePropertiesFile true]] ]')
If a properties file refers to a resource of type Server,
Node, Application, Cluster, or AuthorizationGroup that does not exist
in the target environment, consider setting the GenerateTemplates
option to true:
AdminTask.extractConfigProperties('[-propertiesFileName server.props -configData Server=
-options [[GenerateTemplates true][PortablePropertiesFile true]] ]')
When
the GenerateTemplates option is used, the extracted properties file
has properties sections that support creation of another object of
the same type. By default this option is disabled.
- Optional: Open an editor on the extracted properties
file and examine the resource identifiers to ensure that they are
portable.
Portable identifiers do not identify each
resource uniquely. The following examples show portable identifiers
in various subsections of properties files.
Example
1: Using an attribute name and a value for a resource identifier
In
this example, jndiName is a portable resource identifier
that identifies a DataSource:
#
# SubSection 1.0.1.0 # DataSource attributes
#
Resou:rceType=DataSource
ImplementingResourceType=JDBCProvider
ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:JDBCProvider=Derby JDBC
Provider(XA):DataSource=jndiName#jdbc/DefaultEJBTimerDataSource
Example
2: Using multiple attribute name and value pairs for a resource identifier
In
this example, the nodeName and serverName attributes
together identify the coreGroupServer resource.
#
# SubSection 1.0.8.0 # CoreGroupServer Section
#
ResourceType=CoreGroupServer
ImplementingResourceType=CoreGroup
ResourceId=Cell=!{cellName}:CoreGroup=!{coreGroup}:CoreGroupServer=nodeName#myNode04,serverName#server1
AttributeInfo=coreGroupServers
Example 3: Singleton resource identifier
In
this example, there is only one Security object in the cell. Because
the Security object is considered a singleton object, no attribute
is required to identify this resource uniquely.
#
# SubSection 1.0 # Security Section
#
ResourceType=Security
ImplementingResourceType=Security
ResourceId=Cell=!{cellName}:Security=
Avoid trouble: Some resources,
such as JDBCProvider and ThreadPool, can be created with the same
name multiple times. The name value is the key attribute for these
objects. Do not create multiple instances of these objects with the
same name under a given scope.
gotcha
- Modify the extracted properties file as needed.
- If the extracted portable properties file refers to a resource
of type Server, Node, Application, Cluster, or AuthorizationGroup
that does not exist in the other environment and the extractConfigProperties
command was run with the GenerateTemplates option set to true,
edit the properties file to enable creation of the resource.
The
GenerateTemplates option enables you to create another server that
is similar to an existing server. For example, when server properties
are extracted using this option, the extracted properties file has
a template at the top of the file to create another server. The template
section is skipped by default. If you set SKIP=false and
then set the required properties to create a new object, the product
creates a new object when the applyConfigProperties command is run
and supplies the edited properties file. Because the following sections
contain configuration properties of an existing server and those sections
are processed when the applyConfigProperties command is run, the newly
created server has the same configuration as the old server from which
the properties file was extracted.
You must modify the environment
section to reflect the new server that is created by changing the nodeName, cellName and serverName variables.
This
option generates a template properties section in front of each of
server, cluster, application, and authorization group section. The
sections are disabled by default.
For each object that does
not exist in target environment, edit the section corresponding to
that object. Insert proper properties values and remove SKIP=true.
Set environment specific variables at the end of the properties file
that reflect the new target environment.
- Do not modify or delete properties that are used as keys to identify
an object.
If you modify or delete a key attribute in an object,
then subsequent sections of the properties file must not reference
the object again. The resource specified in the subsequent sections
will not be found.
For example, examine the virtual host properties
in the following sections:
ResourceType=VirtualHost
ImplementingResourceType=VirtualHost
ResourceId=Cell=!{cellName}:VirtualHost=admin_host
#
#Properties
#
name=admin_host #required
#
# SubSection 1.0.1 # MimeTypes section
#
ResourceType=VirtualHost
ImplementingResourceType=VirtualHost
ResourceId=Cell=!{cellName}:VirtualHost=admin_host
AttributeInfo=mimeTypes(type,extensions)
If name=admin_host is
changed to name=my_host, the Mime Types section that
has ResourceId==!{cellName}:VirtualHost=admin_host will
not be able to find the resource specified by ResourceId because the
name is changed in the previous section. Similarly, if name=admin_host is
deleted, the Mime Types section will not be able to find the resource
specified by ResourceId.
- Validate the properties file.
Run the validateConfigProperties
command. See the topic on validating properties files.
- Copy the extracted portable properties file to another
environment.
- If the extracted portable properties file refers to a resource
of type Server, Node, Application, Cluster, or AuthorizationGroup
that does not exist in the other environment and the extractConfigProperties
command was not run with the GenerateTemplates option set to true,
create the resource in the other environment.
Because
the properties file originally applied to a different environment,
a resource identifier in the properties file might refer to a resource
that does not exist in the target environment. If a resource of type
Server, Node, Application, Cluster, or AuthorizationGroup does not
exist in the target environment and the properties files does not
enable creation of the resource, create the resource in the target
environment before applying the properties for that resource. Also,
an attribute might reference another resource. Ensure that all the
referenced resources exist and, if necessary, create resources of
type Server, Node, Application, Cluster, or AuthorizationGroup that
are missing.
- Apply the extracted portable properties file in the other
environment using the applyConfigProperties command.
For
example, to apply the properties file server.props and
generate a report named rep.txt, run following
wsadmin command:
AdminTask.applyConfigProperties('[-propertiesFileName server.props -reportFileName rep.txt]')
If a resource that is specified in
the properties file exists in the target environment and the property
value that is specified in the properties file is the same as what
is already set in the target environment, that property is skipped
or not set in target environment. The product only applies the properties
that are different from what is specified in the properties file.
If
a resource that is specified in the properties file does not exist
in the target environment, the product creates a new resource and
sets all the properties for the newly created resource from the values
for the resource in the properties file. The product does not create
resources of type Server, Node, Application, Cluster, or AuthorizationGroup
unless the extractConfigProperties command was run with the GenerateTemplates
option set to true and the properties file specifies
one or more new resources of those types.