System administration for WebSphere Application Server V7: Part 4: Properties-based configuration

IBM® WebSphere® Application Server V7 introduces properties-based configuration, a new feature that helps you conveniently manage and modify your WebSphere Application Server configuration using properties files. This article explains what properties file based configuration is and how it makes managing your configuration easier than ever. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

John Chang (jchang3@us.ibm.com), Advisory Software Engineer, IBM

John Chang is an Advisory Software Engineer with IBM. He works on WebSphere Application Server development in Austin, TX. John worked on WebSphere security and systems management before joining the WebSphere Web Services team, where he works primarily on WebSphere Web services administration. You can reach John at jchang3@us.ibm.com.



Amy Lin (amylin@us.ibm.com), Staff Software Engineer, IBM

Amy Lin is a Staff Software Engineer at the IBM Austin on the WebSphere System Management team. She is currently the wsadmin scripting development lead and responsible for WebSphere wsadmin development to support multiple scripting languages (Jacl and Jython). Prior to this, she has worked on J2EE 1.4, mixed cell and admin security projects for WebSphere Application Server 4.0 and 6.0 releases. She holds a Master of Science degree in Computer Engineering and Bachelor of Science in Computer Science degree from the University of Texas at Austin.



Vishwanath Venkataramappa (vish@us.ibm.com), Senior Software Engineer, IBM

Vishwanath Venkataramappa is a senior software engineer with IBM working on WebSphere Application Server development in Austin. Vishwanath worked on the WebSphere security team before joining the WebSphere system administration team, where he works primarily on WebSphere configuration.



Syed-Muasir Khalil (smkhalil@us.ibm.com), Software Engineer, IBM

Syed-Muasir Khalil works as a lead in the WebSphere naming functional test team, and is also a function test developer for WebSphere application management components.



08 April 2009

Also available in Chinese

Introduction

IBM WebSphere Application Server configuration is mainly composed of XML format files, along with some non-XML format files. These configuration files are spread across several directories in the WebSphere Application Server installation or configuration tree. The contents of these files are structured in a WebSphere-specific format to adhere to the underlying configuration model.

These configuration objects can be accessed and manipulated with a number of administration tools, such as wsadmin commands, the administrative console, and public Java™ APIs. Each tool offers unique tasks to modify different parts of the configuration. For example, wsadmin contains AdminConfig, AdminTask, AdminApp, and AdminControl tasks to query and modify different objects within a WebSphere Application Server configuration. Leveraging these and other available wsadmin functions traditionally requires an administrator with a thorough understanding of all available tasks.

WebSphere Application Server V7.0 introduces a simple properties file based configuration feature that can be used as a single general tool for querying and modifying configuration objects within a WebSphere Application Server configuration. With this utility, you can examine and update the configuration by extracting configuration elements into a human readable properties file, modify the extracted properties file as necessary, and then apply the changes back to the configuration. Ultimately, this means that you now only need to know one set of commands -- rather than a set of commands per tool -- to configure WebSphere Application Server.

This article provides examples to illustrate how you can extract WebSphere Application Server configuration information into a simple properties file, how to modify the extracted properties file, and finally how to apply your modifications back to the WebSphere Application Server configuration.


Properties-based configuration

Properties-based configuration provides the ability to configure an environment to match the content specified in a properties file. A properties file is created by extracting property names and values from an existing configuration. You can configure an environment by modifying, adding, or deleting objects and attributes in the file and then apply the properties file to a configuration by invoking apply and delete commands.

A properties file contains a list of property name and property value pairs. This data can be used to configure a cell, node, cluster, server, application, or any other configuration object. A properties file, however, is not a configuration file, and so modifications to this file will not affect the configuration of a system until it is applied to the configuration using properties file based configuration.

Properties-based configuration provides two-way translation between the complex data in the WebSphere Application Server configuration repository and a simple properties-based file format that contains comparable configuration information. Properties file based configuration enables you to:

  • Extract data out of the configuration repository to create properties files.
  • Update a properties file to manipulate the configuration, as needed.
  • Apply the updated data in the properties file to a target configuration repository.

Your WebSphere Application Server configuration can be extracted into a single file and any configuration attribute can be located in that file in the form of name/value pair properties. Whereas existing tools, such as wsadmin or the administrative console, require you to invoke specific commands or navigate through multiple panels to get to the required configuration attributes, this new feature utility enables you to get at the entire configuration by extracting it -- or even just an instance of a configuration object and its attributes -- to a properties file.

The two major advantages of using properties-based configuration are:

  • Configuration data is decoupled from changes in the underlying configuration and object model between different releases of WebSphere Application Server.
  • Properties files are more consumable for human administrators than a mix of XML and other formats spread across multiple configuration repositories.

As such, the tool will make the proper conversions from properties file configuration data to the underlying configuration model for that release, giving you the flexibility to use the same configuration data across different versions. Perhaps more importantly, new changes to the configuration can be specified as part of the properties file and applied quickly without requiring an understanding the underlying configuration or object models. For further ease of use, you can apply a working configuration to another system quickly with one command that applies the configuration attributes specified in the properties file, as opposed to other tools, such as wsadmin, that require you to invoke multiple commands to achieve similar results.

Properties-based configuration is not a replacement for configarchive tools; rather, it complements them. The properties extracted from the configuration only contain the most commonly used configuration attributes and will not contain the entire configuration. Whereas, configarchive contains an exact copy of the configuration and can be applied to another system to achieve an exact replica. Since a properties file only contains the most commonly used and key properties, this tool can be used in conjunction with configarchive to make any necessary configuration changes after an archive is imported.

Figure 1. Properties file based configuration
Figure 1. Properties file based configuration

Properties file based configuration commands

Properties file based configuration is implemented as set of AdminCommands, shown in the tables below. These commands can be used from wsadmin or from within a Java client program. (There is no admin console support for properties-based configuration in WebSphere Application Server V7.0.)

Table 1. extractConfigProperties
CommandDescriptionTargetObjectParametersReturnValue
extractConfigPropertiesUse to extract configuration data in the form of a simple properties file. If no configuration object is specified, the entire profile’s configuration data is extracted into the properties file. All environment specific values (cellName, serverName, nodeName, clusterName, coreGroup, nodeGroup, authorizationGroup, and so on) will be expressed as variables. These variables will be stored at the end of the generated properties file.ConfigId of the config object. This is not required if configData parameter is used.
  • propertiesFileName (String, optional): Name of properties file. This is a required parameter.
  • configData (String, optional): Config object instance in the form (Node=node1).
  • filterMechanism (String, optional): Valid values are All (default), NO_SUBTYPES, SELECTED_SUBTYPES.
  • selectedSubTypes (String[], optional): Should be supplied if SELECTED_SUBTYPES is chosen for filterMechanism. Subtypes (config types) within the config object selected under configData parameter.
propertiesFile filled with configuration properties
Examples:

Interactive mode (Jython):
AdminTask.extractConfigProperties ('[-interactive]')

Batch mode (Jython):
AdminTask.extractConfigProperties('[‘-propertiesFileName’ ‘my.props’, ‘-configData’ ‘Node=node1’]')

Table 2. applyConfigProperties
CommandDescriptionTargetObjectParametersReturnValue
applyConfigPropertiesUse to apply properties specified in a properties file to the configuration. Attribute corresponding to each property specified in the properties file is modified with the new value. If attribute corresponding to the specified property does not exist in the configuration, a new attribute is created in the configuration. If a configuration object specified in the properties file does not exist in the configuration, a new configuration object will be created.None
  • propertiesFileName (String, required): Name of properties file
  • variablesMapFile (String, optional): Name of variables map file. This file should contain values for variables used within the properties file.
  • variablesMap (Properties, optional): Variables map that provides values to be used for variables used in the properties file.
  • reportFile (String, optional): A report file that contains report of the operation.
  • reportFilterMechanism (String , optional): Valid values are All (default), Errors, Errors_And_Changes.
  • validate( Boolean, optional): Default is true. Validates properties file before applying.
None
Examples:

Interactive mode (Jython):
AdminTask.applyConfigProperties ('[-interactive]')

Batch mode (Jython):
AdminTask.applyConfigProperties('[‘-propertiesFileName’ ‘my.props’]')

Table 3. validateConfigProperties
CommandDescriptionTargetObjectParametersReturnValue
validateConfigPropertiesUse to validate properties specified in a properties file . This command verifies each property to make sure that no error occurs when it is applied on the configuration. It also validates syntax and checks for proper types. All errors in the properties file will be logged to specified report file. It also logs information such as what configuration objects will be created, which configuration objects will be modified, and so on.None
  • propertiesFileName (String, required): Name of properties file
  • variablesMapFile (String, optional): Name of variables map file. This file should contain values for variables used within the properties file.
  • variablesMap (Properties, optional): Variables map that provides values to be used for variables used in the properties file.
  • reportFile (String, required): A report file that contains report of the operation.
  • reportFilterMechanism (String , optional): Valid values are All (default), Errors, Errors_And_Changes.
None
Examples:

Interactive mode (Jython):
AdminTask.validateConfigProperties ('[-interactive]')

Batch mode (Jython):
AdminTask.validateConfigProperties('[‘-propertiesFileName’ ‘my.props’ ‘-reportFile’ ‘report.ext’]')

Table 4. deleteConfigProperties
CommandDescriptionTargetObjectParametersReturnValue
deleteConfigPropertiesUse to delete properties specified in a properties file from the configuration. Attribute to each property in the properties file is removed. If an attribute has a default value, the attribute value will be set to the default value.None
  • propertiesFileName (String, required): Name of properties file
  • variablesMapFile (String, optional): Name of variables map file. This file should contain values for variables used within the properties file.
  • variablesMap (Properties, optional): Variables map that provides values to be used for variables used in the properties file.
  • reportFile (String, optional): A report file that contains a report of the operation.
  • reportFilterMechanism (String , optional): Valid values are All (default), Errors, Errors_And_Changes.
  • validate( Boolean, optional): Default is true. Validates properties file before deleting.
None
Examples:

Interactive mode (Jython):
AdminTask.deleteConfigProperties ('[-interactive]')

Batch mode (Jython):
AdminTask.deleteConfigProperties('[‘-propertiesFileName’ ‘my.props’]')

Table 5. createPropertiesFileTemplates
CommandDescriptionTargetObjectParametersReturnValue
createPropertiesFileTemplatesUse to create template properties file that can be used to create or delete an instance of specified object type. None
  • propertiesFileName (String, required): Name of properties file
  • configType (String, required): Resource type for which template files needs to be created
None
Examples:

Interactive mode (Jython):
AdminTask. createPropertiesFileTemplates ('[-interactive]')

Batch mode (Jython):
AdminTask. createPropertiesFileTemplates (‘[‘-propertiesFileName’ ‘serverTemplate.props’ ‘-configType’ ‘Server’]')


Anatomy of a properties file

Since a properties file can contain properties of multiple configuration objects and each configuration object can contain multiple properties, a properties file is divided into multiple sections. Each section contains properties of one configuration object. Each section contains a section header followed by name/value property pairs. The section header identifies the configuration object, and the properties section contains the properties of the configuration object.

Listing 1 shows an example of a properties file showing the header and properties of an object.

Listing 1
#
# Section 1.0 ## cells/myCell|cell.xml#Cell_1
#

#
# SubSection 1.0 # Cell level attributes (Header)
#
ResourceType=Cell
ImplementingResourceType=Cell
ResourceId=Cell=!{cellName}
#

#
#Properties section
#
cellType=DISTRIBUTED
name=!{cellName}
...

EnvironmentVariablesSection
#
#Environment Variables
#
cellName=MyCell

The properties file header contains:

  • ResourceType indicates the type of resource.
  • ResourceId is a name that uniquely identifies the resource or configuration object. This should only be modified when the same properties needs to be applied to another object of same type.
  • ImplementingResourceType indicates the class that implements the translation of attributes to properties.

The information in the header is generated automatically, and only ResourceId should ever be modified. This information is present so that the properties file based configuration tool knows which implementation to invoke and apply properties.

The properties section contains properties of the configuration object identified by the header, in name/value pairs. Each name and value corresponds to an attribute of the configuration object.

The environment variables section contains values for variables used within the properties file. Environment specific properties, such as cellName, serverName, nodeName, and so on. are expressed as variables and the current values of those variables are placed at the end of the properties file.

There are several parameters and rules you can apply to a properties files to manipulate a configuration. Here are some of the most common and important ones:

  • Complex properties

    As described earlier, a properties file contains multiple sections. Each section contains a section header that identifies a configuration object, followed by the properties. In most cases, a property within a section corresponds to an attribute of a configuration object. In other cases, however, multiple attributes are combined to form a single property to reduce the size of the generated properties file. When multiple attributes are combined to form a single property, AttributeInfo in the header is used to describe how the multiple attributes are combined. Listing 2 shows an example of how multiple attributes are combined into a single property.

    Listing 2
    #
    # Section 1.0.0 ## cells/myCell|virtualhosts.xml#VirtualHost_1
    #
    
    #
    # SubSection 1.0 # Virtual Hosts
    #
    ResourceType=VirtualHost
    ImplementingResourceType=VirtualHost
    ResourceId=Cell=myCell:VirtualHost=ID#VirtualHost_1
    #
    
    #
    #Properties
    #
    name=default_host
    ...
    #
    # SubSection 1.2 # HostAlias section
    #
    ResourceType=VirtualHost
    ImplementingResourceType=VirtualHost
    ResourceId==myCell:VirtualHost=ID#VirtualHost_1
    AttributeInfo=aliases(port,hostname)
    #
    
    #
    #Properties
    #
    9472=*
    9443=*
    9468=*
    9096=*
    80=*
    ...

    AttributeInfo in the header section contains the information required to map each HostAlias to a single property (port=hostname). It is not imperative that you understand how AttributeInfo is processed internally to map these properties to configuration attributes, but it is important that you do not remove that information from the header. To add a new alias, a new entry can be simple added at the end of the list; when the properties file is applied, the new host alias will be created.

  • List of values

    A property value which is list of values is specified within { } symbols. A classpath property that is a list will be represented as shown in Listing 3. An empty list is specified as {}.

    Listing 3
    #
    # SubSection 1.0 # JDBCProvider attributes
    #
    ResourceType=JDBCProvider
    ImplementingResourceType=JDBCProvider
    ResourceId=Cell=myCell:JDBCProvider=ID#builtin_jdbcprovider
    #
    
    #
    #Properties
    #
    classpath={${DERBY_JDBC_DRIVER_PATH}/derby.jar,/my.jar}
    implementationClassName=org.apache.derby.jdbc.EmbeddedXADataSource
    name=Derby JDBC Provider (XA)
    nativepath={}
    description=Built-in Derby JDBC Provider (XA)
    providerType=Derby JDBC Provider (XA)
    xa=true #boolean
  • Value is not set (null value)

    If a value of a property is not set in the configuration, it will be represented as null (Listing 4).

    Listing 4
    #
    # SubSection 1.0 # ServerCluster attributes
    #
    ResourceType=ServerCluster
    ImplementingResourceType=ServerCluster
    ResourceId=Cell=myCell:Cluster=MMc1
    #
    
    #
    #Properties
    #
    name=MMc1
    preferLocal=true #boolean
    nodeGroupName=null
    stateManagement=null
    enableHA=false #boolean
    uniqueId=null
    serverType=APPLICATION_SERVER #ENUM
    shortName=null
    description=null
    statisticsProvider=null
  • Type of property

    Type of property (int, long, float, an so on) is represented as shown in Listing 5. If type is not mentioned, it defaults to string.

    Listing 5
    #
    # SubSection 1.0.2.0.2 # Monitoring Policy Section
    #
    ResourceType=MonitoringPolicy
    ImplementingResourceType=Server
    ResourceId=Cell=myCell:Node=myNode:Server=server1:
    	MonitoringPolicy=ID#MonitoringPolicy_1
    AttributeInfo=monitoringPolicy
    #
    
    #
    #Properties
    #
    maximumStartupAttempts=3 #integer
    pingTimeout=300 #integer
    pingInterval=60 #integer
    autoRestart=true #boolean
    nodeRestartState=STOPPED #ENUM
  • Required property to create a new object

    If a property is required for a given object, it is represented as shown in Listing 6. This property should exist in the properties file used to create a new object.

    Listing 6
    #
    # Create parameters
    # These parameters should be set to create a new instance of the following type 
    # of object.
    # Replace the line `CreateTemplate=true` with 'CreateDeleteCommandProperties=true'
    # and set actual values for the following properties to create a new object.
    #
    ResourceType=Server
    ImplementingResourceType=Server
    ResourceId=Server=
    CreateTemplate=true
    #
    
    #
    #Properties
    #
    name=name #String,required
    templateLocation=null #javax.management.ObjectName
    genUniquePorts=null #Boolean
    commandName=createApplicationServer
    specificShortName=null #String
    clusterName=null #String
    targetObject=targetObject #ObjectName,required
    templateName=null #String
    genericShortName=null #String
  • Readonly property

    A readonly property should not be changed. In Listing 7, taskName, mutables, and row0 properties are unmutable. All other properties (rows) can be modified.

    Listing 7
    #
    # SubSection 1.1 # MapModulesToServers Section. taskName,mutables and row0 should 
    # not be edited.
    #
    ResourceType=Application
    ImplementingResourceType=Application
    ResourceId=Cell=myCell:Application=ivtApp
    #
    
    #
    #Properties
    #
    taskName=MapModulesToServers #readonly
    mutables={false false true false false false} #readonly
    row0={module uri server ModuleVersion moduletype moduletypeDisplay} #readonly
    row2={"IVT Application" ivt_app.war,WEB-INF/web.xml WebSphere:cell=myCell:
    	node=myNode,server=server1 12 moduletype.web "Web Module"}
    row1={"IVT EJB Module" ivtEJB.jar,META-INF/ejb-jar.xml WebSphere:cell=myCell,
    	node=myNode,server=server1 12 moduletype.ejb "EJB Module"}
  • Property value reference to another object

    If a property value contains a reference to another object, the display name of the object is set as its value (Listing 8). If there is no display name for the referenced object, the complete configId is set as its value.

    Listing 8
    #
    # SubSection 1.0.1.2 # TCP Inbound Transport Channels
    #
    ResourceType=TCPInboundChannel
    ImplementingResourceType=Server
    ResourceId=Cell=myCell:Node=myNode:Server=serve
    r1:TCPInboundChannel=ID#TCPInboundChannel_1
    #
    
    #
    #Properties
    #
    maxOpenConnections=20000 #integer
    name=TCP_3
    hostNameIncludeList={}
    hostNameExcludeList={}
    endPointName=WC_adminhost_secure
    inactivityTimeout=60 #integer
    discriminationWeight=0 #integer
    ddressIncludeList={}
    addressExcludeList={}
    threadPool=WebContainer #ObjectName(ThreadPool)
  • Property value containing space or other special characters

    A property value containing a space or other special characters is enclosed within “ “ (Listing 9).

    Listing 9
    #
    # SubSection 1.1 # TimerManagerInfo section
    #
    ResourceType=TimerManagerInfo
    ImplementingResourceType=TimerManagerProvider
    ResourceId=Cell=myCell:Cluster=MMc1:TimerManagerInfo=ID#TimerMana
    gerInfo_Default
    #
    
    #
    #Properties
    #
    name=DefaultTimerManager
    referenceable=null
    category=null
    defTranClass=null
    providerType=null
    numAlarmThreads=2 #integer
    jndiName="tm/default"
    serviceNames={}
    provider=TimerManagerProvider #ObjectName(TimerManagerProvider)
    description=WebSphere Default TimerManager
  • Special properties

    These special properties can be added to a properties file to indicate whether to skip or process a given section when applying properties file to configuration:

    • SKIP

      Every section can have a SKIP property set to true or false. This property is only used by applyConfigProperties and deleteConfigProperties commands. Default value is false. When this property exists in a section and set to true, that section will be skipped.

      When processing a section with the applyConfigProperties command, if the configuration object corresponding to that section is missing, it will be automatically created. When processing a section with the deleteConfigProperties command, if the configuration data corresponding to that section is missing, no action is taken.

      Example: SKIP=true

    • SKIPSUBSECTIONS

      When this property is present in a section and is set to true, all the subsections are skipped. Default value is false. Subsections are determined by going through all the sections that are contained within the section that contains this variable parameter.

      Example: SKIPSUBSECTIONS=true

    • DELETE

      When this property is present in a section and is set to true, that section will be deleted completely from the configuration. The configuration object corresponding to that section will also be deleted.

      Example: DELETE=true


Usage examples

Now that you have a high level understand of the purpose of the properties file and how it is meant to be used, here are specific examples to illustrate how to use the properties file based configuration utility:

Extract configuration properties

The ExtractConfigProperties command can be used to extract configuration data from the system in the form of properties. This command enables you to extract either the entire cell’s configuration or just a part of configuration.

  • Example 1: Extract entire cell configuration

    Use the command below to extract the configuration for an entire cell. The extracted file looks like Listing 10.

    wsadmin> AdminTask.extractConfigProperties('[-propertiesFileName cell.props ]')

    Listing 10
    # Cell.props
    
    #
    # SubSection 1.0 # Cell level attributes
    #
    ResourceType=Cell
    ImplementingResourceType=Cell
    ResourceId=Cell=!{cellName}
    #
    
    #
    #Properties
    #
    shortName=null
    cellType=DISTRIBUTED #ENUM(UDP|TCP|MULTICAST|DISTRIBUTED|STANDALONE),readonly
    name=!{cellName}
    multicastDiscoveryAddressEndpointName=null
    discoveryAddressEndpointName=null
    cellDiscoveryProtocol=TCP #ENUM(UDP|TCP|MULTICAST)
    
    ...
    ...  Properties of nodes,servers, clusters, applications, etc.
    ... 
    
    
    EnvironmentVariablesSection
    #
    #
    #Environment Variables
    #Thu Apr 17 05:38:01 CDT 2008
    cellName=MyCell

    Notice the !{cellName} variable. The properties file will not have actual cellName, nodeName, serverName, clusterName, applicationName, coreGroup, or nodeGroup values. Instead, these values are expressed as variables. The EnvironmentVariables section at the bottom of the file contains all the variables used in the properties file.

  • Example 2: Extract a server configuration

    Use the command below to extract a server configuration. The extracted file looks like Listing 11.

    wsadmin> AdminTask.extractConfigProperties('[-propertiesFileName server.props -configData Server=dmgr ]')

    Listing 11
    #
    # SubSection 1.0 # Server Section
    #
    ResourceType=Server
    ImplementingResourceType=Server
    ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}
    #
    
    #
    #Properties
    #
    shortName=null
    serverType=DEPLOYMENT_MANAGER #readonly
    developmentMode=false #boolean
    parallelStartEnabled=true #boolean
    name=!{serverName}
    clusterName=null
    uniqueId=null
    modelId=null
    
    …
    … Properties of other inner objects ( EJBContainer, WebContainer, ORB etc) 
    …  and  subtypes not shown.
    …
    
    EnvironmentVariablesSection
    #
    #Environment Variables
    #
    cellName=MyCell
    nodeName=MyNodeManager
    hostName=MyHost
    serverName=dmgr
  • Example 3: Extract servers’s EJBContainer and WebContainer properties

    This command can be used to extract just the EJBContainer properties of a server:

    wsadmin> AdminTask.extractConfigProperties('[-propertiesFileName ejbcontainer.props -configData Server=dmgr -filterMechanism SELECTED_SUBTYPES -selectedSubTypes [EJBContainer ] ]')

    This command can be used to extract both EJBContainer and WebContainer properties:

    wsadmin> AdminTask.extractConfigProperties('[-propertiesFileName container.props -filterMechanism SELECTED_SUBTYPES –selectedSubTypes [EJBContainer WebContainer ] ]')

    The extracted properties file will just have properties for EJBContainer and WebContainer as shown in Listing 12.

    Listing 12
    #
    # SubSection 1.0 # EJBContainer
    #
    ResourceType=EJBContainer
    ImplementingResourceType=EJBContainer
    ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:
    ApplicationServer=ID#ApplicationServer_1:EJBContainer=ID#EJBContainer_1
    AttributeInfo=components
    #
    
    #
    #Properties
    #
    EJBTimer={} #ObjectName*(null)
    name=null
    defaultDatasourceJNDIName=null
    inactivePoolCleanupInterval=30000 #long
    passivationDirectory="${USER_INSTALL_ROOT}/temp"
    enableSFSBFailover=false #boolean
    server=null
    parentComponent=Network Deployment Server
    
    #
    # SubSection 1.0 # WebContainer 
    #
    ResourceType=WebContainer
    ImplementingResourceType=WebContainer
    ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:
    ApplicationServer=ID#ApplicationServer_1:WebContainer=ID#WebContainer_1
    AttributeInfo=components
    #
    
    #
    #Properties
    #
    enableServletCaching=false #boolean
    name=null
    defaultVirtualHostName=null
    server=null
    maximumPercentageExpiredEntries=15 #integer
    asyncIncludeTimeout=60000 #integer
    parentComponent=Network Deployment Server
    disablePooling=false #boolean
    sessionAffinityFailoverServer=null
    maximumResponseStoreSize=100 #integer
    allowAsyncRequestDispatching=false #boolean
    sessionAffinityTimeout=0 #integer
    	
    EnvironmentVariablesSection
    #
    #Environment Variables
    #
    cellName=MyCell
    nodeName=MyCellManager
    hostName=MyHost
    serverName=dmgr

    Notice the EJBContainer=ID#EJBContainer_1 statement in the ResourceId line. This uniquely represents the EJBContainer object within the server. Since the name field in this case is null, you have to use the xmi ID to represent this object. Also, xmi ID is the only way to uniquely identify an object in the configuration, as the same name can be used to create multiple objects in many cases. However, you can modify this field to EJBContainer=myContainer if the name field is set to myContainer in the configuration, before applying the properties file to the configuration.

  • Example 4: Extract node properties without traversing the contents (subtypes) of the node

    The command below will extract properties for a node without extracting properties of its subtypes (such as servers and resources). The resulting properties file will look like Listing 13, without any subtype information.

    wsadmin> AdminTask.extractConfigProperties('[-propertiesFileName node.props -configData Node=MyCellManager -filterMechanism NO_SUBTYPES]')

    Listing 13
    #
    # SubSection 1.0 # Node Section
    #
    ResourceType=Node
    ImplementingResourceType=Node
    ResourceId=Cell=!{cellName}:Node=!{nodeName}
    #
    
    #
    #Properties
    #
    shortName=null
    name=!{nodeName}
    maxFilePermissionForApps=".*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755
    "
    discoveryProtocol=TCP #ENUM(UDP|TCP|MULTICAST)
    hostName=!{hostName}
    
    #
    ## Section 1.0_1#Cell=!{cellName}:Node=!{nodeName}
    #
    ResourceType=Node
    ImplementingResourceType=Node
    ExtensionId=NodeMetadataExtension
    ResourceId=Cell=!{cellName}:Node=!{nodeName}
    
    #
    nodeOS=distributed
    nodeVersion=7.0.0.0
    
    #
    # End of Section 1.0# Cell=!{cellName}:Node=!{nodeName}
    #
    
    EnvironmentVariablesSection
    #
    #Environment Variables
    #Thu Apr 17 14:27:01 CDT 2008
    cellName=MyCell
    nodeName=MyCellManager
  • Example 5: Extract node properties without traversing the contents (subtypes) of the node, and without invoking any extensions

    The command below can be used to extract node properties without including properties from extensions. Listing 14 is the result of this command. Notice that the NodeMetadataExtension section is missing, because that is an extension to the Node resource.

    wsadmin> AdminTask.extractConfigProperties('[-propertiesFileName node.props -configData Node=MyCellManager -filterMechanism NO_SUBTYPES_AND_EXTENSIONS]')

    Listing 14
    #
    # SubSection 1.0 # Node Section
    #
    ResourceType=Node
    ImplementingResourceType=Node
    ResourceId=Cell=!{cellName}:Node=!{nodeName}
    #
    
    #
    #Properties
    #
    shortName=null
    name=!{nodeName}
    maxFilePermissionForApps=".*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755
    "
    discoveryProtocol=TCP #ENUM(UDP|TCP|MULTICAST)
    hostName=!{hostName}
    
    
    #
    # End of Section 1.0_1# Cell=!{cellName}:Node=!{nodeName}
    #
    
    EnvironmentVariablesSection
    #
    #Environment Variables
    #
    cellName=MyCell
    nodeName=MyCellManager

Modify extracted properties files and apply back to the configuration

After extracting the configuration file, one or more properties values can be modified using any text editor, and then applied back to the configuration using the applyConfigProperties command.

  • Example 1: Modify one or more properties and apply properties file to configuration

    In this example, the enableSFSBFailover property of EJBContainer is changed from false to true in the properties file.

    Listing 15
    #
    # File : ejbcontainer.props
    #
    # SubSection 1.0 # EJBContainer
    #
    ResourceType=EJBContainer
    ImplementingResourceType=EJBContainer
    ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:
    ApplicationServer=ID#ApplicationServer_1:EJBContainer=ID#EJBContainer_1
    AttributeInfo=components
    #
    
    #
    #Properties
    #
    EJBTimer={} #ObjectName*(null)
    name=null
    defaultDatasourceJNDIName=null
    inactivePoolCleanupInterval=30000 #long
    passivationDirectory="${USER_INSTALL_ROOT}/temp"
    enableSFSBFailover=true #boolean
    server=null
    parentComponent=Network Deployment Server
    
    EnvironmentVariablesSection
    #
    #Environment Variables
    #
    hostName2=*
    hostName1=localhost
    cellName=MyCell
    nodeName=MyCellManager
    hostName=MyHost
    serverName=dmgr
    enableSSB=true

    After modifying the properties file, you can run this command to apply the properties to the system. The changes can then be verified by extracting the properties again.

    wsadmin> AdminTask.applyConfigProperties('[-propertiesFileName ejbcontainer.props ]')

  • Example 2: Using additional user defined variables

    In this example, the same property (enableSFSBFailover) is modified by using a variable !{enableSSB} for its value. The variable can be used in the section header or in the properties area of the section. Also, a property value can be made up of multiple variables, as shown for ResourceId. In Listing 16, the EnvironmentVariableSection should be modified to include any new variables used.

    Listing 16
    #
    # File : ejbcontainer.props
    #
    # SubSection 1.0 # EJBContainer
    #
    ResourceType=EJBContainer
    ImplementingResourceType=EJBContainer
    ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:
    ApplicationServer=ID#ApplicationServer_1:EJBContainer=ID#EJBContainer_1
    AttributeInfo=components
    #
    
    #
    #Properties
    #
    EJBTimer={} #ObjectName*(null)
    name=null
    defaultDatasourceJNDIName=null
    inactivePoolCleanupInterval=30000 #long
    passivationDirectory="${USER_INSTALL_ROOT}/temp"
    enableSFSBFailover=!{enableSSB} #boolean
    server=null
    parentComponent=Network Deployment Server
    
    EnvironmentVariablesSection
    #
    #
    #Environment Variables
    #
    hostName2=*
    hostName1=localhost
    ellName=MyCell
    nodeName=MyCellManager
    hostName=MyHost
    serverName=dmgr
    enableSSB=true

    After making the changes to the properties file, the properties file can be applied using the same command:

    wsadmin> AdminTask.applyConfigProperties('[-propertiesFileName ejbcontainer.props ]')

  • Example 3: Using a different variableMap file instead of the one inside the properties file

    In this example (Listing 17), all variables are placed in a different file (Listing 18).

    Listing 17
    # File : ejbcontainer.props
    #
    # SubSection 1.0 # EJBContainer
    #
    ResourceType=EJBContainer
    ImplementingResourceType=EJBContainer
    ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:
    ApplicationServer=ID#ApplicationServer_1:EJBContainer=ID#EJBContainer_1
    AttributeInfo=components
    #
    
    #
    #Properties
    #
    EJBTimer={} #ObjectName*(null)
    name=null
    defaultDatasourceJNDIName=null
    inactivePoolCleanupInterval=30000 #long
    passivationDirectory="${USER_INSTALL_ROOT}/temp"
    enableSFSBFailover=!{enableSSB} #boolean
    server=null
    parentComponent=Network Deployment Server
    Listing 18
    #File : ejbprops.vars:
    
    #
    #
    #Environment Variables
    #
    hostName2=*
    hostName1=localhost
    cellName=MyCell
    nodeName=MyCellManager
    hostName=MyHost
    serverName=dmgr
    enableSSB=true

    This command can now be used to apply the properties file using a different variables map file:

    wsadmin>AdminTask.applyConfigProperties('[-propertiesFileName ejbcontainer.props -variablesMapFileName ejbprops.vars ]')

Validate properties file

A properties file modified using a text editor should be validated before you apply the file to a configuration. A separate command is provided to do this. However, the applyConfigProperties command will also perform validation by default before it applies the properties to the configuration. If the properties file is already validated, then validation during apply can be disabled by selecting an option in the applyConfigProperties command.

  • Example 1: Validate properties file

    When applying a properties file, validation should be performed for the entire properties file by default. However, you can use the command below to validate a properties file separately. The command will generate a report file that will look like Listing 19.

    wsadmin> AdminTask.validateConfigProperties('[-propertiesFileName ejbcontainer.props -variablesMapFileName ejbprops.vars -reportFileName report.txt ]')

    Listing 19
    ADMG0820I: Start applying properties from file ejbcontainer.props
    ADMG0818I: Processing section EJBContainer:ApplicationServer.
    ADMG0810I: Not changing value for this property EJBTimer. New value specified 
    is same as current value {}.
    ADMG0810I: Not changing value for this property defaultDatasourceJNDIName. New 
    value specified is same as current value null.
    ADMG0811I: Changing value for this property enableSFSBFailover. New value specified 
    is true. Old value was false.
    ADMG0810I: Not changing value for this property inactivePoolCleanupInterval. New 
    value specified is same as current value 30000.
    ADMG0810I: Not changing value for this property name. New value specified is same 
    as current value null.
    ADMG0807I: Property parentComponent is readonly. Will not be modified
    ADMG0810I: Not changing value for this property passivationDirectory.
     New value specified is same as current value ${USER_INSTALL_ROOT}/temp.
    ADMG0807I: Property server is readonly. Will not be modified
    ADMG0819I: End Processing section EJBContainer:ApplicationServer.

    The report file shown in Listing 19 is verbose. It reports:

    • Any change to the property value (value in configuration is different from what is in properties file).
    • No change to a property value (value in configuration is same as what is in properties file).
    • Read-only types of properties that cannot be changed.
    • Other errors.

    To make the generated report file more concise, you can specify the reportFilterMechanism parameter to report:

    • only report errors
    • errors and any changes to configuration
    • all.

    For example, the command below can be used to report just errors and changes. The report file generated will just have the information shown in Listing 20 (in this case, there is an error and a configuration change).

    wsadmin> AdminTask.validateConfigProperties('[-propertiesFileName ejbcontainer.props -variablesMapFileName ejbprops.vars -reportFileName report.txt -reportFilterMechanism Errors_And_Changes ]')

    Listing 20
    ADMG0820I: Start applying properties from file ejbcontainer.props
    ADMG0811I: Changing value for this property enableSFSBFailover. New value 
    specified is true. Old value was false. 
    ADMG0831I: Value specified for property inactivePoolCleanupInterval is not 
    a valid type. Specified value asdf, Required type long.
    ADMG0821I: End applying properties from file ejbcontainer.props.

    Listing 20 contains one message about a change that will happen to the configuration, and another message about an invalid value specified for a property. It has one change to a configuration and one error.

  • Example 2: Validate properties file during apply

    When applying a properties file, validation is performed for the entire properties file by default. If there is any problem in the properties file, no changes will be made to the configuration. If there are no problems with the properties file, then the properties file is applied as planned. If the properties file is already validated prior to the apply, then you can set the validate parameter to false as shown here:

    wsadmin> AdminTask.applyConfigProperties('[-propertiesFileName ejbcontainer.props -variablesMapFileName ejbprops.vars -validate false]')

  • Example 3: Generate reports during apply

    All the configuration changes made as a result of applying a properties file can be logged in a report file by specifying the report file name parameter, as shown below. The report file generated looks like Listing 21.

    wsadmin> AdminTask.applyConfigProperties('[-propertiesFileName ejbcontainer.props -variablesMapFileName ejbprops.vars –reportFileName report.txt ]')

    Listing 21
    ADMG0820I: Start applying properties from file ejbcontainer.props
    ADMG0818I: Processing section EJBContainer:ApplicationServer.
    ADMG0810I: Not changing value for this property EJBTimer. New value specified is
    same as current value {}.
    ADMG0810I: Not changing value for this property defaultDatasourceJNDIName. New 
    value specified is same as current value null.
    ADMG0811I: Changing value for this property enableSFSBFailover. New value specified
    is true. Old value was false.
    ADMG0810I: Not changing value for this property inactivePoolCleanupInterval. New
    value specified is same as current value 30000.
    ADMG0810I: Not changing value for this property name. New value specified is same
    as current value null.
    ADMG0807I: Property parentComponent is readonly. Will not be modified
    ADMG0810I: Not changing value for this property passivationDirectory.
     New value specified is same as current value ${USER_INSTALL_ROOT}/temp.
    ADMG0807I: Property server is readonly. Will not be modified
    ADMG0819I: End Processing section EJBContainer:ApplicationServer.

    As in Listing 19, the report file shown in Listing 21 is verbose. You can specify the reportFilterMechanism parameter to make the generated report more concise. For example, you can use this command to report just errors and changes, and the report generated willlook like Listing 22.

    wsadmin>AdminTask.applyConfigProperties('[-propertiesFileName ejbcontainer.props -variablesMapFileName ejbprops.vars –reportFileName report.txt -reportFilterMechanism Errors_And_Changes ]')

    Listing 22
    ADMG0820I: Start applying properties from file ejbcontainer.props
    ADMG0811I: Changing value for this property enableSFSBFailover. New value 
    specified is true. Old value was false. 
    ADMG0831I: Value specified for property inactivePoolCleanupInterval is not a valid 
    type. Specified value asdf, Required type long.
    ADMG0821I: End applying properties from file ejbcontainer.props.

    Listing 22 contains one message about a change that will happen to the configuration, and another message about an invalid value specified for a property. It has one change to configuration and one error.

Create new objects

To create objects of type server, cluster, application, and authorizationgroup, the properties file template should be created first using the createPropertiesFileTemplates command. You should modify this template properties file (as described in the comments section of the generated file) and then use the applyConfigProperties command to create a new object. For example, you could follow the three steps below to create a new AuthorizationGroup:

  1. Generate properties file template

    Use the command below to create a properties file template that can later be used to create a new object. This command will create a template file as shown in Listing 23.

    wsadmin>AdminTask.createPropertiesFileTemplates('[-propertiesFileName ag.template -configType AuthorizationGroup ]')

    Listing 23
    #
    # Create parameters
    # Replace the line `SKIP=true` with 'SKIP=false' under each section that is needed
    # Set necessary parameters under each command or step sections
    # Invoke applyConfigProperties command using this properties file.
    #
    ResourceType=AuthorizationGroup
    ImplementingResourceType=AuthorizationGroup
    ResourceId=AuthorizationGroup=
    SKIP=true
    CreateDeleteCommandProperties=true
    #
    
    #
    #Properties
    #
    authorizationGroupName=authorizationGroupName #String,required
    commandName=createAuthorizationGroup
  2. Modify the generated template file

    Modify the generated file (Listing 23) by setting the required parameters (at a minimum) and changing SKIP=true to SKIP=false. The modified file should look like Listing 24.

    Listing 24
    #
    # Create parameters
    # Replace the line `SKIP=true` with 'SKIP=false' under each section that is needed
    # Set necessary parameters under each command or step sections
    # Invoke applyConfigProperties command using this properties file.
    #
    ResourceType=AuthorizationGroup
    ImplementingResourceType=AuthorizationGroup
    ResourceId=AuthorizationGroup=
    SKIP=false
    CreateDeleteCommandProperties=true
    #
    
    #
    #Properties
    #
    authorizationGroupName=ag1 #String,required
    commandName=createAuthorizationGroup
  3. Apply the configuration using the modified template file

    Use the applyConfigProperties command to create a new authorization group object. This will create a new authorization group (ag1).

    AdminTask.applyConfigProperties('[-propertiesFileName ag.template ]')

Delete existing objects

To delete objects of type server, cluster, application, or authorizationgroup, you should first create a properties file template using the createPropertiesFileTemplates command. Modify the template properties file as described in the comments section of the generated file and then use the deleteConfigProperties command to delete an existing object. For example, to delete an existing AuthorizationGroup:

  1. Generate properties file template

    Use the command below to create a properties file template to use later for creating a new object. This command will create a template file as shown in Listing 25.

    wsadmin>AdminTask.createPropertiesFileTemplates('[-propertiesFileName ag.template -configType AuthorizationGroup ]')

    Listing 25
    #
    # Delete parameters
    # Replace the line `SKIP=true` with 'SKIP=false' under each section that is needed
    # Set necessary parameters under each command or step sections
    # Invoke deleteConfigProperties command using this properties file.
    #
    ResourceType=AuthorizationGroup
    ImplementingResourceType=AuthorizationGroup
    ResourceId=AuthorizationGroup=
    SKIP=true
    CreateDeleteCommandProperties=true
    #
    
    #
    #Properties
    #
    authorizationGroupName=authorizationGroupName #String,required
    commandName=deleteAuthorizationGroup
  2. Modify the generated template file

    Modify the generated file by setting the required parameters (at a minimum) and changing SKIP=true to SKIP=false. The modified file should look like Listing 26.

    Listing 26
    #
    # Delete parameters
    # Replace the line `SKIP=true` with 'SKIP=false' under each section that is needed
    # Set necessary parameters under each command or step sections
    # Invoke deleteConfigProperties command using this properties file.
    #
    ResourceType=AuthorizationGroup
    ImplementingResourceType=AuthorizationGroup
    ResourceId=AuthorizationGroup=
    SKIP=false
    CreateDeleteCommandProperties=true
    #
    
    #
    #Properties
    #
    authorizationGroupName=ag1 #String,required
    commandName=deleteAuthorizationGroup
  3. Delete a configuration using the modified template file

    Use the deleteConfigProperties command to delete an existing authorization group object. This command will delete the authorization group (ag1):

    AdminTask.deleteConfigProperties('[-propertiesFileName ag.template ]')

Create and delete objects

To create objects of type server, cluster, application, or authorization group, use the template properties file, as explained earlier. However, most of other types of objects can be created by modifying an extracted properties file and modifying the ResourceId field, such that the resource represented by that ResourceId does not exist in the configuration. When the applyConfigProperties command is invoked using the properties file that contains a non-existing resource ID, the command will try to create a new object.

  • Example 1: Create a new ThreadPool using a properties file (using an ID not in the configuration)

    Suppose Listing 27 is a section in the extracted properties file. Here, the object already exists in the configuration.

    Listing 27
    #
    # SubSection 1.0.1.4 # Thread pools
    #
    ResourceType=ThreadPool
    ImplementingResourceType=Server
    ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:Thr
    eadPoolManager=ID#ThreadPoolManager_1:ThreadPool=ID#builtin_ThreadPool_4
    #
    
    #
    #Properties
    #
    maximumSize=20 #integer
    name=Default
    inactivityTimeout=5000 #integer
    minimumSize=5 #integer
    isGrowable=false #boolean

    You can modify the ResourceId such that the thread pool represented by that ResourceId does not exist. In Listing 28, this thread pool, ThreadPool_9999 ID, does not exist in the configuration.

    Listing 28
    #
    # SubSection 1.0.1.4 # Thread pools
    #
    ResourceType=ThreadPool
    ImplementingResourceType=Server
    ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:Thr
    eadPoolManager=ID#ThreadPoolManager_1:ThreadPool=ThreadPool_99999
    #
    
    #
    #Properties
    #
    maximumSize=20 #integer
    name=myThreadPool
    inactivityTimeout=5000 #integer
    minimumSize=5 #integer
    isGrowable=false #boolean

    Now, if the applyConfigProperties command is invoked using this properties file, a new ThreadPool will be created:

    wsadmin> AdminTask.applyConfigProperties('[-propertiesFileName thp.props ]')

  • Example 2: Create a new ThreadPool using properties file (using thread pool name not in the configuration)

    Instead of using a random ID that does not exist in the configuration, you can also specify the name of an object if that object has the name attribute, and the specified name does not already exist in the configuration. Listing 29 shows a properties file that uses name instead of an ID.

    Listing 29
    #
    # SubSection 1.0.1.4 # Thread pools
    #
    ResourceType=ThreadPool
    ImplementingResourceType=Server
    ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:Thr
    eadPoolManager=ID#ThreadPoolManager_1:ThreadPool=myThreadPool
    #
    
    #
    #Properties
    #
    maximumSize=20 #integer
    name=myThreadPool
    inactivityTimeout=5000 #integer
    minimumSize=5 #integer
    isGrowable=false #boolean

    When the applyConfigProperties command is invoked using this properties file, it will create a new threadPool:

    wsadmin> AdminTask.applyConfigProperties('[-propertiesFileName thp.props ]')

  • Example 3: Delete an existing object using deleteConfigProperties command

    To delete an object, use the deleteConfigProperties command. For example, to delete the threadpool you just created in Example 2, you can run the command using the same properties file that was used to create it, but with DELETE=true in the header, as shown in Listing 30.

    Listing 30
    #
    # SubSection 1.0.1.4 # Thread pools
    #
    ResourceType=ThreadPool
    ImplementingResourceType=Server
    ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:Thr
    eadPoolManager=ID#ThreadPoolManager_1:ThreadPool=myThreadPool
    DELETE=true
    #
    
    #
    #Properties
    #
    maximumSize=20 #integer
    name=myThreadPool
    inactivityTimeout=5000 #integer
    minimumSize=5 #integer
    isGrowable=false #boolean

    Alternatively, rather than use ThreadPool=myThreadPool, you could use ThreadPool=ID#ThreadPool_12345 instead. You must make sure that the ID you enter (“ThreadPool_12345” here) is the actual ID in the configuration for this object.

    Use the deleteConfigProperties command with the above properties file to delete the object. This will delete the thread pool represented by the properties file from the configuration:

    wsadmin> AdminTask.deleteConfigProperties('[-propertiesFileName thp.props ]')

    Know that if DELETE is not specified, the deleteConfigProperties command will try to delete each property and leave the object in the configuration. When each property is removed from the object, the property will either reset to the default value (if there is one) or it will be removed.

More examples

Here are some examples of additional functions you can perform using properties file based configuration:

  • Install an application using properties file

    When the properties file in Listing 31 is applied using the applyConfigProperties command, the application specified in the properties file will be installed.

    Listing 31
    # Header
    ResourceType=Application
    ImplementingResourceType=Application
    ResourceId=Deployment=
    
    # Properties
    Name=hello
    TargetServer=server1
    TargetNode=node1
    EarFileLocation=/temp/Hello.ear
    #TargetCluster=cluster1
  • Uninstall an application using properties file

    When the properties file in Listing 32 is applied using the deleteConfigProperties command, the application specified in the properties file will be uninstalled.

    Listing 32
    # Header
    ResourceType=Application
    ImplementingResourceType=Application
    ResourceId=Deployment=hello
    
    # Properties
    Name=hello
  • Update an application using properties file

    To update an application that is already installed, you can use the applyConfigProperties command to perform a variety of updates using a properties file. To add a single file, invoke the applyConfigProperties command with a properties file like the one shown in Listing 33.

    Listing 33
    # Header
    ResourceType=Application
    ImplementingResourceType=Application
    ResourceId=Deployment=hello
    
    # Properties
    Name=hello
    Update=true
    operationType=add
    contentType=file
    contentURI=test.war/com/ibm/addMe.jsp
    contentFile=c:/temp/addMe.jsp

    To update an application that is already installed, you can use the applyConfigProperties command to perform a variety of updates using a properties file. To add a single file, invoke the applyConfigProperties command with a properties file like the one shown in Listing 33.

    Listing 33
    # Header
    ResourceType=Application
    ImplementingResourceType=Application
    ResourceId=Deployment=hello
    
    # Properties
    Name=hello
    Update=true
    operationType=add
    contentType=file
    contentURI=test.war/com/ibm/addMe.jsp
    contentFile=c:/temp/addMe.jsp

    To delete a single file, invoke the applyConfigProperties command with a properties file like the one shown in Listing 34.

    Listing 34
    # Header
    ResourceType=Application
    ImplementingResourceType=Application
    ResourceId=Deployment=hello
    
    # Properties
    Name=hello
    Update=true
    operationType=delete
    contentType=file
    contentURI=test.war/com/ibm/addMe.jsp

    To add a module, invoke the applyConfigProperties command using a properties file like the one shown in Listing 35.

    Listing 35
    # Header
    ResourceType=Application
    ImplementingResourceType=Application
    ResourceId=Deployment=hello
    
    # Properties
    Name=hello
    Update=true
    operationType=add
    contentType=moduleFile
    #contextRoot=”/mywebapp” # required for webmodule only
    contentURI= Increment.jar
    contentFile= c:/apps/app1/Increment.jar
    deployEJB=false

    To delete a module, invoke the applyConfigProperties command with a properties file like the one shown in Listing 36.

    Listing 36
    # Header
    ResourceType=Application
    ImplementingResourceType=Application
    ResourceId=Deployment=hello
    
    # Properties
    Name=hello
    Update=true
    operationType=delete
    contentType=moduleFile
    contentURI= test.war

    To perform a partial update, invoke the applyConfigProperties command using a properties file similar to the one shown in Listing 37.

    Listing 37
    # Header
    ResourceType=Application
    ImplementingResourceType=Application
    ResourceId=Deployment=hello
    
    # Properties
    Name=hello
    Update=true
    operationType=update
    contentType=partialapp
    contentFile= c:/temp/MyApp/myAppPartial.zip

    To perform a full update, invoke the applyConfigProperties command with a properties file like the one shown in Listing 38.

    Listing 38
    # Header
    ResourceType=Application
    ImplementingResourceType=Application
    ResourceId=Deployment=hello
    
    # Properties
    Name=hello
    Update=true
    operationType=update
    contentType=app
    contentFile= c:/apps/app1/newApp1.ear
    useDefaultBindings=true

Summary

Properties-based configuration is a new and unique way to monitor and manage your IBM WebSphere Application Server V7.0 configuration. It provides a much easier way to manage your WebSphere Application Server environment because it doesn't require a deep understanding of the complex configuration model or significant programming skill. Still, you must take special care when updating your configuration, since the behavior of the application server depends directly on the configuration parameters. This article provided examples for what can be configured (and how) using properties-based configuration. You will find more information on this topic and details about this feature in the WebSphere Application Server Information Center.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=380280
ArticleTitle=System administration for WebSphere Application Server V7: Part 4: Properties-based configuration
publish-date=04082009