I have skimmed over the posts from the last few days. I think that I have caught the gist of the config discussion. Bear with me if I have missed anything.
I don't believe that any of the proposed mailet config formats actually give you a structured mailet config. All they do is address matcher config. We are still stuck with name/value pairs for mailet config - and we are sticking ourselves with the same limitation for matchers, too.
Here is an example of how I think that mailet configuration should look:
-----------------------------------
<processor name="root"
xmlns='http://james.apache.org/config/'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:schemaLocation='http://james.apache.org/config/ james-config.xsd'
xmlns:nvp="http://james.apache.org/config/NameValuePairs/";>
<config-parsers>
<parser namespace="http://james.apache.org/config/NameValuePairs"; class="NameValuePairConfigParser"/>
<parser namespace="http://mydomain.org/mycustomconfig"; class="MyCustomConfigParser"/>
</config-parsers>
<!-- In the simplest case, name value pairs would be used for configuration
of both matchers and mailets.
-->
<mailet class="Whatever">
<matcher class="UserIs">
<config>
<nvp:param name="p1" value="x"/>
<nvp:param name="p2" value="y"/>
</config>
</matcher>
<config>
<nvp:param name="p1" value="x"/>
<nvp:param name="p2" value="y"/>
</config>
</mailet>
<!-- In more complex cases, arbitrary XML from another namespace is used -->
<mailet class="Whatever">
<matcher class="UserIs">
<config>
<nvp:param name="p1" value="x"/>
<nvp:param name="p2" value="y"/>
</config>
</matcher>
<config xmlns:mycfg="http://mydomain.org/mycustomconfig";>
<mycfg:foo>
<mycfg:bar attr="value"/>
</mycfg:foo>
</config>
</mailet>
</processor>
-----------------------------------
The <config-parsers> should really be outside of the <processor> tag, but it was easier to write the accompanying schema this way.
A parser is responsible for taking a snippet of XML and creating a java object from it that implements a Config interface. This object is then obtained by the mailet/matcher via a API call.
In the event that no parser is configured for a given namespace, a default config object is returned, which contains the contents of the <config> tag as a DOM tree.
[Noel]
On the same note, is there a reason not to use a DTD/XSD for JAMES config?How would you validate the configuration? How do you know which elements are valid or necessary for a given attribute VALUE? :-)
I do not understand this objection at all. Attributes don't contain elements. See the attached XSD for an example of how I see this working. What this provides is basically free structural validation of the config file - why not use it? We also get a *really* excellent way of documenting the config file format by running a XSLT transformation to pluck out the documentation from the XSD. (This could be made to work similarly to javadoc.)
Danny has voiced his strong opposition to the use of namespaces in the james config. While I respect his opinion, I did not see an actual argument against namespace use (other than that it would cause Danny to chew off his leg). Is there a reason for this objection? ;-)
If complexity is the reason, I do not believe that the example I have provided is really particularly complex, given the benefits gained. As Noel mentions, the namespace stuff would never make it into the Mailet API.
Exposing a DOM tree in the Mailet API would only be done through a default implementation of the Config interface. Thus, it would not actually be part of the core API. I only propose this as a convenience for those who do not wish to write a ConfigParser for their mailet.
Kenny mentions that populating a java bean with property values by relection, a-la struts form beans is a good idea. This could be useful in the case of the name/value pairs config format. For other formats, this brings you straight back to the current one name, one value issue.
Someone else (I can't remember who) mentioned backward compatibility and ease of upgrades. I cannot see a way to make a significant improvement on the current config functionality without breaking backward compatibility. However, it ought to be possible to write an XSLT stylesheet that will convert from the old format to the new format, making upgrades fairly easy.
Before we proceed much further - are we all OK with the concept of breaking backward compatibility in the config file format?
ADK
<?xml version="1.0" encoding="UTF-8"?>
<!--
Document : james-config.xml
Created on : 1 January 2003, 23:48
Author : adk
Description:
Purpose of the document follows.
-->
<processor name="root"
xmlns='http://james.apache.org/config/'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:schemaLocation='http://james.apache.org/config/ james-config.xsd'
xmlns:nvp="http://james.apache.org/config/NameValuePairs/";>
<config-parsers>
<parser namespace="http://james.apache.org/config/NameValuePairs"; class="NameValuePairConfigParser"/>
<parser namespace="http://mydomain.org/mycustomconfig"; class="MyCustomConfigParser"/>
</config-parsers>
<!-- In the simplest case, name value pairs would be used for configuration
of both matchers and mailets.
-->
<mailet class="Whatever">
<matcher class="UserIs">
<config>
<nvp:param name="p1" value="x"/>
<nvp:param name="p2" value="y"/>
</config>
</matcher>
<config>
<nvp:param name="p1" value="x"/>
<nvp:param name="p2" value="y"/>
</config>
</mailet>
<!-- In more complex cases, arbitrary XML from another namespace is used -->
<mailet class="Whatever">
<matcher class="UserIs">
<config>
<nvp:param name="p1" value="x"/>
<nvp:param name="p2" value="y"/>
</config>
</matcher>
<config xmlns:mycfg="http://mydomain.org/mycustomconfig";>
<mycfg:foo>
<mycfg:bar attr="value"/>
</mycfg:foo>
</config>
</mailet>
</processor>
<?xml version="1.0" encoding="UTF-8"?>
<!--
Document : james-config.xsd
Created on : 1 January 2003, 22:52
Author : adk
Description:
Purpose of XML Schema document follows.
-->
<xsd:schema targetNamespace="http://james.apache.org/config/";
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:james="http://james.apache.org/config/";>
<xsd:element name="processor">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="james:config-parsers" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="james:mailet" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:NCName" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="config-parsers">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="james:parser" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="parser">
<xsd:complexType>
<xsd:attribute name="namespace" type="xsd:string" use="required"/>
<xsd:attribute name="class" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="mailet">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="james:matcher" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="james:config" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="class" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="matcher">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="james:config" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="class" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="config">
<xsd:complexType mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:anyAttribute namespace="##other"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
