WebLogic Attribute-keyed Parser

Cloud Control provides an attribute-keyed parser provided by Oracle specifically designed to parse the WebLogic config.xml file. It has the same parameters as the default XML parser and comes with 26 default post-parsing rules to uniquely identify nodes with the same name.

WebSphere Attribute-keyed Parsers

Cloud Control provides several attribute-keyed parsers provided by Oracle designed to parse specific WebSphere configuration files. Each parser has the same parameters as the default XML parser and comes with a set of default post-parsing rules to uniquely identify nodes with the same name. There are parsers for the following WebSphere configuration files:

• node.xml (1 default post-parsing rule)

• plugin-cfg.xml (7 default post-parsing rules)

• resource.xml (9 default post-parsing rules)

• server.xml (13 default post-parsing rules)

• variables.xml (1 default post-parsing rule)

WebSphere Generic Parser

Cloud Control provides one generic parser provided by Oracle designed to parse the WebSphere serverindex.xml configuration file. It comes with three default post-parsing rules to uniquely identify nodes with the same name.

This section contains three XML parser examples:

• As parsed using the default XML parser, with parameter values provided by Oracle

• As parsed using the default XML parser, with modified parameter values

• As parsed using the generic XML parser

Parsed examples derive from the following original XML file:

  <?xml version="1.0" encoding="UTF-8"?>
  <Application>
     <AppName>foo</AppName>
     <Server name="ajax" os="linux">production</Server>
  </Application>

Default XML Parser (Parameter Values Provided by Oracle)

When parsed using the default XML parser with parameter values provided by Oracle, the parsed version appears as follows:

  Application
     AppName = foo  
     Server 
        name = ajax
        os = linux
        text_value = production
         

Note the following about this parsed version:

• The element contents of the AppName and Server tags become parsed attributes.

• Since the AppName tag contains no XML attributes, the parsed attribute name takes the tag name.

• Contrast with the Server tag, which has XML attributes (name and os). This results in a container named for the tag (Server), with three parsed attributes, one for each of the XML attributes, and a third for the text content of the Server tag, which is set to the value of the STORE_CONTENT_AS parameter (text_value).

Default XML Parser (Modified Parameter Values)

To modify parameter values, you have to create a new parser by exporting the default XML parser, modifying the exported XML file, and importing the modified parser, using a new name and parser ID.

Assume you followed this process, making the following modifications:

• Set the STORE_CONTENT_AS parameter to the value myVal

• Set the CONTAINER_NAME parameter to the value name

When parsed using the default XML parser with modified parameter values, the parsed version appears as follows:

  Application
     AppName = foo  
     ajax 
        os = linux
        myVal = production
         

Note the following about this parsed version:

• The AppName tag remains the same; that is, it has no XML attributes so it becomes a parsed attribute.

• Since the Server tag has an XML attribute that matches the value of CONTAINER_NAME, the container takes the value of the attribute (ajax), obviating the name=ajax parsed attribute. Remember that the CONTAINER_NAME parameter provided by Oracle has a placeholder but no actual default value; thus, the difference in this version of the parsed representation.

• The remaining Server tag attribute (os) becomes a parsed attribute as usual, and the text content associated with the tag becomes the value of the attribute myVal, per the edited STORE_CONTENT_AS parameter.

Generic XML Parser

When parsed using the generic XML parser (the one that takes no parameters), the parsed version appears as follows:

  Application
     AppName 
        text_value = foo
     Server 
        name = ajax
        os = linux
        text_value = production
         

See About the Default XML Parser for a reminder of how parsing occurs.

Simple Property

A simple property consists of a property name, cell delimiter, property value, and newline sequence, in that order. A simple property may take up more than one line, although properties that span multiple lines usually contain a line continuation character or sequence. The parser ignores whitespace such as tabs and spaces, unless a parameter specifies whitespace as having some significance (cell delimiter, for example).

Example: name=value_that_wraps_to_next_line_/, where the forward slash serves as a line continuation character. A Java Properties file typifies this data format.

Keyword Property

This construct is the same as a simple property, only with a keyword in front, which the parser ignores.

Example: set name=value, where set is the ignored keyword. A Unix System file typifies this data format.

Keyword Name Property

This construct is a simple property where the property name matches a regular expression specified in the KEYWORD_FIELD parser parameter. This is a special case property type specific to the Unix XINETD parser. The XINETD file uses an equal sign (=) as a cell delimiter except when the property begins with the keyword "include" or "includedir", in which case the cell delimiter is whitespace.

While added specifically for XINETD files, the property can be used for other file types where appropriate.

Example: includedir /etc, where includedir is the parser parameter regular expression and whitespace is the cell delimiter.

Explicit Property

An explicit property consists of a property name, a delimiter, and a property value. Unlike a simple or keyword property, an explicit property is bound to a container construct such as a section or a structure; an XML tag attribute, for example.

Examples:

[SectionName p1=v1 p2=v2]

<StructureName p1=v1 p2=v2>
...
</StructureName>

In these constructs, the name value pairs p1 v1 and p2 v2 are explicit properties. A Sun ONE Obj file typifies this data format.

Implicit Property

An implicit property is a property value without an associated property name. Like an explicit property, an implicit property is bound to a container construct, usually a reserved directive. The DIRECTIVE_PROPERTIES parser parameter contains the property names of implicit properties.

Examples:

[SectionName myName myPath]

<StructureName myName myPath>
...
</StructureName>

In these constructs, the implicit properties have the values myName and myPath, with the presumed property names name and path, as declared in the DIRECTIVE_PROPERTIES parser parameter. An Apache HTTPD file typifies this data format.

Reserved Function

A reserved function is a keyword followed by one or more explicit properties. The RESERVED_FUNCTIONS parser parameter specifies keywords that denote reserved functions.

Example: Error fn="query-handler" type="forbidden", where Error is the reserved function keyword specified in the RESERVED_FUNCTIONS parser parameter. A Sun ONE Magnus file typifies this data format.

Reserved Directive

A reserved directive is a keyword followed by one or more implicit properties. The RESERVED_DIRECTIVES parser parameter specifies keywords that denote reserved directives.

Example: LoadModule cgi_module "/bin/modules/std/cgi", where LoadModule is the reserved function keyword specified in the RESERVED_DIRECTIVES parser parameter. An Apache HTTPD file typifies this data format.

XML Structure

An XML structure is a standard XML tag that can contain a name only, a name followed by explicit properties, or a name followed by implicit properties.

Examples:

<Name>
...
</Name>

<Name p1=v1 p2=v2>
...
</Name>
<Name "implicit_property1" "implicit_property2">
...
</Name>

A WebAgent file typifies this data format.

Delimited Structure

A delimited structure consists of the following (in the specified order):

• Structure name

• Delimiter

• Start structure character or character sequence

• Structure contents

• End structure character or character sequence

Example:

StructureName = {
...
}

Explicit and implicit properties are not allowed. Java Policy and Custom CFG files typify this data format.

Structure

A structure consists of the following (in the specified order):

• Structure name

• Start structure character or character sequence

• Structure contents

• End structure character or character sequence

The only difference between a delimited structure and a structure is the delimiter; that is, a structure does not require a delimiter between the structure name and the start structure indicator.

Example:

StructureName {
...
}

Explicit and implicit properties are not allowed. A Unix XINETD file typifies this data format.

INI Section

And INI section resembles a section heading in a Windows .ini file, characterized by:

• Section start character or character sequence

• Section name

• Optional (explicit and implicit) properties

• Section end character or character sequence

Examples:

[SectionName]

[SectionName p1=v1 p2=v2]

[SectionName "implicit_property1" "implicit_ property2"]

SmWalker and Sectioned Properties files typify this data format.

Delimited Section

A delimited section is a line that begins with a common pattern, but otherwise resembles a simple property.

Examples:

HKEY_LOCAL_MACHINE\SOFTWARE\A\B\C=789

HKEY_LOCAL_MACHINE\SOFTWARE\X\Y\Z=123

These are two delimited section headings where the common pattern is HKEY_. SiteMinder Registry and LDAP files typify this data format.

Element Cell

An element cell consists of an element cell name and a property name value pair of the form A = B = C. Element cells typically use line continuation sequences and nesting to clarify the structure. An element cell that has multiple properties uses a property delimiter to separate them.

Example 1:

EC = \
    B = C, D = F

This example is an element cell named EC with two property name value pairs, B = C and D = F, separated by a comma. The structure uses the backslash character (\) to indicate line continuation. The advanced properties parser parameters PROPERTY_DELIMITER and CONTINUE_LINE define the respective format characters.

Example 2:

EC = \
              EC2 = \
                             A = B, \
                             C = D

This example is an element cell named EC that has a nested element cell named EC2 that contains two property name value pairs, A = B and C = D. This example uses the same delimiter and line continuation characters.

Consider the following simple XML file:

  <dir name="/a/b/c">    
    <file name="file1" size=120/>    
    <file name="file2" size=350/>    
  </dir>

Its parsed form, using the default XML parser, appears in the user interface in the following tree structure:

  dir
     	name    = /a/b/c
        file
                name = file1
                size = 120
        file
                name = file2
                size = 350
         	

Notice that two containers have the same name (file), which makes it impossible to distinguish between the two, at the container level, at least. Thus, this file is a candidate for a post-parsing rule. As mentioned, there is a special internal XML format against which to apply a rule's XPath condition and expression. This format treats nodes and attributes as XML elements, and converts attribute values into corresponding element text content. It also adds a root element that doesn't appear in the original file:

  <root>  
    <dir>
        <name>/a/b/c</name>
        <file>
              <name>file1</name>
              <size>120</size>
        </file>
        <file>
              <name>file2</name>
              <size>350</size>
        </file>
    </dir>
  </root>

Given the problem in the parsed form of having two containers with the same name, a rule resolution might consist of the following:

• Condition: /root/dir/file
• Expression: name/text()

Effectively, this says: for each file evaluate name/text() to produce an identifier that distinguishes one file from another within the dir node.

After applying the post-parsing rule, the parsed tree structure appears as follows:

  dir
        name = /a/b/c
        file[file1]
              name = file1
              size = 120
        file[file2]
              name = file2
              size = 350
         

The rule resolves to an identifier appended in square brackets to the container name. The combination (file[file1], for example) enables various operations such as compare, search, change history, and so forth, to distinguish between file containers.

Consider the following simple ORA file:

  acme=
     (DESCRIPTION=
        (SOURCE_ROUTE=yes)
        (ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=1630))
        (ADDRESS_LIST=
           (FAILOVER=on)
           (LOAD_BALANCE=off)
     (ADDRESS=(PROTOCOL=tcp)(HOST=host2a)(PORT=1630))
           (ADDRESS=(PROTOCOL=tcp)(HOST=host2b)(PORT=1630)))
        (ADDRESS=(PROTOCOL=tcp)(HOST=host3)(PORT=1630))
        (CONNECT_DATA=(SERVICE_NAME=xyz.example.com)))

Its parsed form, using the Oracle ORA parser, appears in the user interface in the following tree structure:

  acme
          DESCRIPTION
               SOURCE_ROUTE    yes
               ADDRESS
                       PROTOCOL         tcp
                       HOST             host1
                       PORT             1630
               ADDRESS_LIST
                       FAILOVER         on
                       LOAD_BALANCE     off
                       ADDRESS
                               PROTOCOL          tcp
                               HOST              host2a
                               PORT              1630
                       ADDRESS
                               PROTOCOL          tcp
                               HOST              host2b
                               PORT              1630
               ADDRESS
                       PROTOCOL         tcp
                       HOST             host3
                       PORT             1630
               CONNECT_DATA
                       SERVICE_NAME     xyz.example.com

Notice that the address containers, both standalone and within ADDRESS_LIST are indistinguishable. Thus, this file is a candidate for a post-parsing rule. As mentioned, there is a special internal XML format against which to apply a rule's XPath condition and expression. This format treats nodes and attributes as XML elements, and converts attribute values into corresponding element text content. It also adds a root element that doesn't appear in the original file:

  <root>
          <acme>
                  <DESCRIPTION>
                          <SOURCE_ROUTE>yes</SOURCE_ROUTE>
                          <ADDRESS>
                                  <PROTOCOL>tcp</PROTOCOL>
                                  <HOST>host1</HOST>
                                  <PORT>1630</PORT>
                          </ADDRESS>
                          <ADDRESS_LIST>
                                  <FAILOVER>on</FAILOVER>
                                  <LOAD_BALANCE>off</LOAD_BALANCE>
                                  <ADDRESS>
                                          <PROTOCOL>tcp</PROTOCOL>
                                          <HOST>host2a</HOST>
                                          <PORT>1630</PORT>
                                  </ADDRESS>
                                  <ADDRESS>
                                          <PROTOCOL>tcp</PROTOCOL>
                                          <HOST>host2b</HOST>
                                          <PORT>1630</PORT>
                                  </ADDRESS>
                          </ADDRESS_LIST>
                          <ADDRESS>
                                  <PROTOCOL>tcp</PROTOCOL>
                                  <HOST>host3</HOST>
                                  <PORT>1630</PORT>
                          </ADDRESS>
                          <CONNECT_DATA>
                                  <SERVICE_NAME>xyz.example.com</SERVICE_NAME>
                          </CONNECT_DATA>
                  </DESCRIPTION>
          </acme>
  </root>

Given the problem in the parsed form of having containers with the same name, a rule resolution might consist of the following:

• Condition: //ADDRESS
• Expression:/HOST/text()

Effectively, this says: for each address element evaluate /HOST/text() to extract the host name as the address identifier.

After applying the post-parsing rule, the parsed tree structure appears as follows:

  acme
          DESCRIPTION
               SOURCE_ROUTE    yes
               ADDRESS[host1]
                       PROTOCOL         tcp
                       HOST             host1
                       PORT             1630
               ADDRESS_LIST
                       FAILOVER         on
                       LOAD_BALANCE     off
                       ADDRESS[host2a]
                               PROTOCOL          tcp
                               HOST              host2a
                               PORT              1630
                       ADDRESS[host2b]
                               PROTOCOL          tcp
                               HOST              host2b
                               PORT              1630
               ADDRESS[host3]
                       PROTOCOL         tcp
                       HOST             host3
                       PORT             1630
               CONNECT_DATA
                       SERVICE_NAME     xyz.example.com

The rule resolves to an identifier appended in square brackets to the container name. The combination (ADDRESS[host2a], for example) enables various operations such as compare, search, change history, and so forth, to distinguish between address containers.

Consider the following three-column database table SERVER_DETAILS:

The SQL query expressed as part of the configuration extension creation is as follows:

select * from SERVER_DETAILS

This query returns the following raw output:

  [row]
  11_SERVER_NAME=13_ webserver-100
  11_ENVIRONMENT=2_ QA
  19_HOSTED_APPLICATIONS=1_5
  [row]
  11_SERVER_NAME=13_ webserver-200
  11_ENVIRONMENT=11_ PERFORMANCE
  19_HOSTED_APPLICATIONS=1_6
  [row]
  11_SERVER_NAME=13_ webserver-500
  11_ENVIRONMENT=10_ PRODUCTION
  19_HOSTED_APPLICATIONS=1_3

The Configuration Browser Source tab renders the data the same way.

Its parsed form, using the Database Query parser, appears in the user interface in the following tree structure:

  row
         SERVER_NAME=webserver-100
         ENVIRONMENT=QA
         HOSTED_APPLICATIONS=5
  row
         SERVER_NAME=webserver-200
         ENVIRONMENT=PERFORMANCE
         HOSTED_APPLICATIONS=6
  row
         SERVER_NAME=webserver-500
         ENVIRONMENT=PRODUCTION
         HOSTED_APPLICATIONS=3

Notice that the row containers are indistinguishable. Thus, this query result is a candidate for a post-parsing rule. As mentioned, there is a special internal XML format against which to apply a rule's XPath condition and expression. This format treats nodes and attributes as XML elements, and converts attribute values into corresponding element text content. It also adds a root element that doesn't appear in the original file:

  <root>
              <row>
                          <SERVER_NAME>webserver-100</SERVER_NAME>
                          <ENVIRONMENT>QA</ENVIRONMENT>
                          <HOSTED_APPLICATIONS>5</HOSTED_APPLICATIONS>
              </row>
              <row>
                          <SERVER_NAME>webserver-200</SERVER_NAME>
                          <ENVIRONMENT>PERFORMANCE</ENVIRONMENT>
                          <HOSTED_APPLICATIONS>6</HOSTED_APPLICATIONS>
              </row>
              <row>
                          <SERVER_NAME>webserver-500</SERVER_NAME>
                          <ENVIRONMENT>PRODUCTION</ENVIRONMENT>
                          <HOSTED_APPLICATIONS>3</HOSTED_APPLICATIONS>
              </row>
  </root> 

Given the problem in the parsed form of having three containers with the same name, a rule resolution might consist of the following:

• Condition:/root/row/SERVER_NAME
• Expression:SERVER_NAME/text()

Effectively, this says: for each row evaluate SERVER_NAME/text() to produce an identifier that distinguishes one row from another within the tree structure.

After applying the post-parsing rule, the parsed tree structure appears as follows:

  row[webserver-100]
         SERVER_NAME=webserver-100
         ENVIRONMENT=QA
         HOSTED_APPLICATIONS=5
  row[webserver-200]
         SERVER_NAME=webserver-200
         ENVIRONMENT=PERFORMANCE
         HOSTED_APPLICATIONS=6
  row[webserver-500]
         SERVER_NAME=webserver-500
         ENVIRONMENT=PRODUCTION
         HOSTED_APPLICATIONS=3

The rule resolves to an identifier appended in square brackets to the container name. The combination (row[webserver-100], for example) enables various operations such as compare, search, change history, and so forth, to distinguish between row containers.