Service module configuration
Configuration data for BOD service modules is organized into base, and custom configuration. Configuration files are loaded before the service module can process service requests. The configuration class loader automatically discovers the configuration directories, by following certain naming conventions.
Configuration file loading
When resolving configuration, custom configuration always takes precedence over base configuration. Depending on the load policy (extend versus override), the base configuration is either parsed or skipped. The load policy is specified in the parser class implementation. You can check whether the policy is overridable by calling the isOverridable() method.
For
more complex configuration data structures, that cannot easily be
represented as name-value pairs (for example, heavily structured,
nested data), you can provide your own configuration file and configuration
parser. This requires more work from the developer, but is completely
flexible - any kind of configuration file can be read, parsed, and
retrieved in your service module Java code. If you are writing your
own configuration parser, must extend from the AbstractConfigurationImpl
abstract
class.
- Extend Policy
- When the extend policy is used, the configuration information for both bootstrap and custom configuration is loaded and returned to the caller as a list of configuration objects. In the list, custom configuration precedes bootstrap configuration. The caller must traverse the list and pick the configuration.
- Override Policy
- If the override policy is used, the loading process only loads the custom configuration. The bootstrap configuration is ignored. Thus, any metadata placed in custom configuration files will completely override the metadata from the base.
During development, you may want to modify and
reload configuration, without having to restart the server. To enable
volatile reloading for all service modules, create an empty .reloadconfig
file
in xml/config/com.ibm.commerce.foundation/
. This
will cause every service module to check the timestamps on its configuration
files, each time it is called. Configuration files that have changed
from the time that they were last loaded will get re-parsed. Also,
if a configuration file was added or removed, all files in the same
directory are reloaded. To enable volatile reloading for a particular
service module, create an empty .reloadconfig
file
under the service module configuration directory . For example, xml/config/com.myco.myservicemodule
.
Volatile reloading will only be enabled for that service module.
Naming conventions
The configuration loader uses directory names to discover a service module's bootstrap and custom configurations.
- Bootstrap configuration
- xml/config/servicemodulename/
- Custom configuration
- xml/config/servicemodulename-ext/
- All WebSphere Commerce default configuration filenames are prefixed by "wc-". For example: wc-query.tpl.
- Administration configuration filenames begin with "wc-admin".
- Descriptive words are joined with dashes. For example, wc-business-context.
- wc-component.xml
- Contains the development configuration of a component. It can occur in both the base and custom configuration directories.
- wc-admin-component.xml
- Contains the administration configuration of a component. It can occur in both the base and custom configuration directories.
- wc-application.xml
- Contains the development configuration information applicable to all components within an application. This file will only exist under the foundation component directory.
- wc-admin-application.xml
- Contains the administration configuration information applicable to all components within an application. This file will only exist under the foundation component directory.
- SDO.properties
- Used for loading the initialized logical SDO classes. Specifies
a class that declares the logical SDO classes that need to be initialized.
For example, the SDO.properties file for the Member component contains:
com.ibm.commerce.member.facade.datatypes.impl.MemberPackageImpl
. - wc-component-client.xml
- Specifies the bindings from URL to Web services. For example,
the component-client.xml for the Member service module is shown in
the following XML sample:
<_config:DevelopmentClientConfiguration xmlns:_config="http://www.ibm.com/xmlns/prod/commerce/foundation/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ibm.com/xmlns/prod/commerce/foundation/config ../xsd/wc-component-client.xsd"> <_config:invocationservice> <_config:invocationbinding bindingImpl="com.ibm.commerce.foundation.internal.client.services.invocation.impl.J2SEWebServiceInvocationBindingImpl"> <_config:property name="url" value="http://hostname:8007/webapp/wcs/component/member/services/MemberServices"/> </_config:invocationbinding> </_config:invocationservice> </_config:DevelopmentClientConfiguration>
- wc-business-object-mediator.xml
- Contains configuration information for the csdbom.html.
- wc-object-relational-metadata.xml
- Contains Object-relational metadata.
xml/config/xsd
directory.
By observing the XML file in an editor, you can use the XSD to determine
the respective supported elements, as well as the annotation about
the configuration.Configuration files
- SDO.properties
- wc-admin-component
- wc-business-context
- wc-business-object-mediator.xml
- wc-component.xml
- wc-component-client.xml
- wc-object-relational-metadata.xml
- wc-query-noun-get.tpl
- wc-query-noun-update.tpl
- SDO.properties
- wc-component.xml
- wc-component-client.xml