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
New feature: You can apply properties
files that have portable resource identifiers to another environment.
newfeat
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.