Due to my exposure to Web Services and the various XML standards,
I have been toying with the concept of a configuration standard
that would provide a rich configuration environment.
The delimna is that we need to provide a solution that is:
* Easy to use
* Provides minimal impact on the current API
* Satisfies a need
* Easily extendable
We currently have two easy to use configuration methodologies:
Configuration and Parameters. We have already discussed that
Parameters' inherently flat design works in some environments
very easily. The Configuration object provides a simple
hierarchical object that tracks hierarchical information well.
Both are simple, satisfies most needs, and already exist in
the API. They are not extendable--but that is by design.
The Configuration object's use can be further helped by the
following additional information: Namespace and Qualified name.
The Configuration object specifies the method getLocation().
It's use is not well documented, so it can be purposed to record
the namespace. The name of the component would be bound to
the local name in the XML. The last remaining issue is the
prefix or qName. Because the prefix is not as important as
the local name or the namespace, a new accessor method can be
provided called "getExtendedName()". It would work like this:
<datasource:jdbc
xmlns:datasource="resource://org/apache/avalon/excalibur/datasource/schema.xsd">
</datasource:jdbc>
conf.getName() == "jdbc"
conf.getLocation() == "resource://org/apache/avalon/excalibur/datasource/schema.xsd"
conf.getExtendedName() == "datasource:jdbc"
This does not interfere with the current API, and only provides
one additional method. What it does allow is the ability to use
industry standards for configuration (WSDL, WSDD, etc.) and to
take advantage of dynamic validation of our configuration schemas.
XML parsers can read the configuration information and validate
the file based on the various schemas, throwing exceptions when
the configuration is invalid.
The Schema approach further strengthens the contract of the Configuration
heirarchy, and takes advantage of modern parsers abilities. In fact,
it helps autodiscovery of the necessary class names by allowing the
Parser to provide the class name and role name for you. It does add
responsibility to the Component developer to provide a current schema.
Understandably, this can be construed as being too XML specific. I have
also been toying with the idea of Configuration providers. Basically,
you would have the ConfigurationBuilder.getInstance("XML") that would
be used to derive the configuration tree from an XML input stream. I
have come to the conclusion that certain sources are better suited for
different Configuration providers. For instance, XML is naturally
hierarchical and works best with Configuration elements. However,
SQL data is naturally flat and works best with Parameters elements.
Not everything can be expressed in the same way equally well--no matter
how easy it is to manipulate in program space.
Each persistence mechanism must follow its own rules. However, it is
conceivable to convert your persisted data into XML which is then able
to be handled in the expected manner. This reduces the amount of learning
curve, hides the details of the persistence mechanism, and allows you
to focus on the task at hand.
It also allows for new tools to be developed. Tools are used to augment
the development process, the configuration process, or the deployment
process. Tools are not used directly in the run-time system--so they
should not be part of any of our existing projects.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
