openInstaller Configuration capabilities

Middleware configuration has been mostly ad-hoc, relying on product installers to be coded with precise, but non-extensible, knowledge of the structure and expectations of configuration requirements.  Configuration data is not exposed outside of the integrated installers in a consistent way, requiring that any applications that wish to provide configuration management capabilities to do so without the help of the work done by the integration effort.  In addition, the incremental cost of adding new components to an already-integrated stack is very high since the already-integrated configuration support is highly coupled and dependent on precise orchestration of the logic for configuring the bundled components.

Through the formalization of the configurator interface, the installer will be only one of many management applications that can drive the configuration mechanism. This effectively separates the development of installers, consoles, remote  monitoring and control mechanisms from that of managed software.  This should improve the ease (in terms of development effort, communication, release engineering and documentation) with which the installer (and other management applications) integrate with the managed software.

So What install developer has to do for configuration!!!Couple of XML file creation,Thats it. Basically installer calls the product configurators through init-config interface, init-config interface can be implemented in user's preferred language.

XML File,open office registry format, contains the configuration attributes to configure the component.Following is the sample XML file that contains the configuration attribute.

<oor:component-schema oor:version="1.1" oor:name="ProductA"
     <group oor:name="Administration">
        <prop oor:name="A_ADMIN_USER" oor:type="xs:string">
             <desc xml:lang="en-US">Administrator Name</desc>
        <prop oor:name="A_ADMIN_PASSWORD" oor:transient="true" oor:type="xs:string">
             <desc xml:lang="en-US">Administrator Password</desc>

The component-schema element contains the name of the component and the package belongs to. The name is used for a number of other purposes and is referred to later on (e.g. When other components' parameters refer to this component and its parameters, the reference must use this name). The package name is unused at this time but remains for compatibility with APOC UI Format. The component-schema element contains exactly one component element, which has no attributes.  Within the component element,that contains one or more groups.

Every group element has a name associated with it, which is used to name the group and is used later to reference a parameter within this group.  Every group can have one or more property elements.

Property elements have a name, type, transient, and nillable attribute.  The name of the property is used to refer to this property.The type is the type of property, used for validation of potential values (e.g. An integer must be an integer, etc). A nillable value can take on the empty value (e.g. “” for a string), and is used for passwords that initially have no default value.  Any parameter which is non-nillable (nillable=false) must have a valid, non-nil default value.  The transient attribute, when set to true, means that the variable must not be stored on non-volatile storage (also used for passwords). The Info element within the group element contains human-readable (and internationalized) text describing the element which can be used to show on a user interface.

Property elements also have zero or more Constraint elements associated with them. Constraints restrict the values that can be assigned to the parameter.  For example:

  <minLength oor:value=”9”/>

Says that the any value must be 9 characters or greater before it will successfully be assigned to this parameter.  There are a number of other basic constraints available (see the appendix and schema for the possible values). The Value element contains the default value for this parameter. It should be domain- and machine-independent.  In other words, the default value should be reasonable under any and all circumstances.  This is the value used when no other value is given.  For example, in many cases, a default value of “” is used for parameters that represent the IP address of a service endpoint:

     <group oor:name="Service Endpoints">
        <prop oor:name="HTTP-Service-IP" oor:type="oor:ip">

Sometimes it is impossible (or not practical or desirable)  to define a single default value, but rather the default value should be computed at runtime,In my next blog I will be talking about the openInstaller's capability of dynamically deducing the default values.

Where to place the component's configurator !!!!

1. openInstaller will, by default, look for product configurators ("init-config") in the ${INSTALL_HOME}/${COMPONENT-ID}/bin directory.  This is an attempt to track the still-evolving multi-install fileystem layout.

2. In addition, it is now possible to override this default location for one or more configurators.To override the location in which openInstaller looks, you can use the Init-Config-Locations engine option.  e.g.
-p Init-Config-Locations=ProdA:/usr/share/lib/iProdA/install

This tells the openInstaller engine that the configurator for the "ProdA" product is in the /usr/share/lib/iProdA/install directory.  Within that directory, openInstaller will first look for "init-config" (assumed to be an executable file),then "init-config.vbs" (visual basic), finally "init-config.bat" (Windows Batch).  You can also specify a direct path to a regular file, which openInstaller interprets as a complete path to the executable.

In general, you can override the defaults for more than one product:

-p Init-Config-Locations=ProdA:/foo,appsvr:/bar/init-config.exe,/baz

This says that the ProdA configurator is in /foo, and that the appsvr configurator is /bar/init-config.exe, and that for all other products, look in /baz.

If a default value (e.g. one with out a "product:" prefix) is left off, then the old default applies ($INSTALL_HOME/<comp>/bin)

In addition, standard openInstaller substitution syntax applies. For example, to specify a location relative to $INSTALL_HOME,one can say:
-p Init-Config-Locations= ProdA::[component:InstallHome:directory:INSTALL_HOME]/relative/path/to/

Notice the double ":" - the first part is "ProdA:" (the prefix telling openInstaller which product), and the second part is ":[subst]" where subst is the standard openInstaller substitution syntax.  This can be used to form very dynamic paths when referencing a number of dynamic variables (port numbers, install directories for other components, IP addresses, etc).
openInstaller configuration framework has the capability to cature the error ,if any, occurs during configuration,and pass back to openInstaller,So the openInstaller can display the proper error message.

There are lot more things about the openInstaller configuration, I will be talking in my next blog.

You can visit to to know more about openInstaller. 


Is this a joke? Do you call this simple? -p Init-Config-Locations= ProdA::[component:InstallHome:directory:INSTALL_HOME]/relative/path/to/ It's horrible! Windows style is simple: [init] product=fruits component=apple location=$HOME path=/relative/path/to/

Posted by Chris on June 04, 2007 at 05:42 AM PDT #

Good post... keep blogging

Posted by Jayanth on June 06, 2007 at 08:15 PM PDT #

Thnx Chris. I agree. But I dont see any problem, in keeping, all values in single string.Its much easier when we have multiple component to install and specify init-config location for all the components.

Posted by sandeep on June 06, 2007 at 08:45 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed



« June 2016