Re: [V3] Mailet/Matcher configuration

[Aaron Knauf <ak...@xtra.co.nz>]

Happy New Year guys.

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

RE: [V3] Mailet/Matcher configuration

["Noel J. Bergman" <no...@devtech.com>]

> 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?  ;-)

Well, Danny's family would probably object to the inconvenience, not to
mention the pain, suffering, and unsightly damage.  And the doctors would be
none too pleased -- can you imagine the surgery to clean up the mess?  True,
with a wireless broadband laptop hooked to the wheelchair, he'd have more
time for coding, but having visited Scotland (East Lothian and the
Cairngorms), I wouldn't trade that for the ablity to hike that incredibly
photogenic region.

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>