You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2002/12/31 22:27:04 UTC
[V3] Mailet/Matcher configuration
Aaron Knauf wrote:
[details:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apache
.org&msgNo=6094]
> A structured mailet config would allow multiple header/property mappings
> to be configured for a single mailet instance, too.
Kenny Smith concured:
> I've only tried to work on 2 mailets so far, but the restriction
> of a name-value pair combo has come up in both of them. I would
> love to have arbitrary XML parsed into a dom, or have the values
> pulled into a bean, etc.
Guys, have you looked at the exchange in [V3] Personal Item List? There is
a proposal that the revised configuration look something like:
<mailet class="Whatever">
<matcher class="Whatever">
<condition>whatever<condition/>
<param name="x" value="y"/>
<matcher/>
<param name="a" value="b">
<mailet/>
Personally, I am very comfortable with XML, but Danny has indicated that he
is unfavorably disposed towards complicating the Mailet API with full DOM
access or the configuration file with more complex XML (e.g., namespaces).
> [Aaron's proposed] scheme would allow mailets to get their config in one
of 3 ways -
> 1) As named properties
> 2) As a DOM tree
> 3) As a custom Config object
Aaron, here is a hook for you to raise your proposal again for discussion.
> 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? :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [V3] Mailet/Matcher configuration
Posted by Kenny Smith <ke...@journalscape.com>.
> Guys, have you looked at the exchange in [V3] Personal Item List?
> There is a proposal that the revised configuration look something
> like:
> <mailet class="Whatever">
> <matcher class="Whatever">
> <condition>whatever<condition/>
> <param name="x" value="y"/>
> <matcher/>
> <param name="a" value="b">
> <mailet/>
>
> Personally, I am very comfortable with XML, but Danny has indicated
> that he is unfavorably disposed towards complicating the Mailet API
> with full DOM access or the configuration file with more complex XML
> (e.g., namespaces).
My absolute perferred method would be similiar to the ActionForm concept
in Struts. That I would define a bean that would be dynamically
populated with my data. So if I had something like (matcher stuff
excluded for now):
<mailet class="Foo">
<config>
<name type="String">Kenny</name>
<something type="int">3</something>
</config>
</mailet>
Then I could get the Config bean for my mailet, cast it to a MyFooConfig
object and call getName() and getSomething() on it and it would return
typed data.
I realize that this is very complicated, but I offer it as my best
solution from the perspective of a developer (and I use the term lightly
*smile*).
>> [Aaron's proposed] scheme would allow mailets to get their config in
>> one of 3 ways -
>> 1) As named properties
>> 2) As a DOM tree
>> 3) As a custom Config object
I like all three options and I'm partial to 2 (although I don't care for
the namespaces complexity) and 3.
Kenny Smith
JournalScape.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [V3] Mailet/Matcher configuration
Posted by "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>
Re: [V3] Mailet/Matcher configuration
Posted by 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