> I would also like to see a slight shift in terminology. Mailets can be
> used by different matchers in different processors, so calling the xml
> element mailet is a bit confusing.
>
> I'd prefer something like (for external config)
>
> <stage name="MyStage" config="file:[EMAIL PROTECTED]">
> </stage>
>
> and for inline config, instead of:
> <mailet match="RemoteAddrNotInNetwork=127.0.0.1,192.168.1"
> class="ToProcessor">
> <processor> spam </processor>
> </mailet>
>
> have:
> <stage name="StopOpenRelays" config="INLINE">
> <match class="RemoteAddrNotInNetwork">
> <allowedNetworks="127.0.0.1,192.168.1"/>
> </match>
> <mailet class="ToProcessor">
> <processor> spam </processor>
> </mailet>
> </stage>
I like this. I like this alot because it opens up the possiblity of
having multiple matchers for a set of mailets or a a set of mailets for
a single matcher. Or even combined.
For example (note: INLINE is the default config)
<stage name="james-dev">
<match class="RecipientIs">
<recipient>[EMAIL PROTECTED]</recipient>
</match>
<mailet class="ToListservArchive">
<path>jdbc://something/cool</path>
</mailet>
<mailet class="ListserveClass">
<!-- listserve options -->
</mailet>
</stage>
<stage name="extraStuff" config="file://somewhere/else.xml"/>
<stage name="MyForwardingAddress" config="INLINE">
<match class="RecipientIs">
<recipient>[EMAIL PROTECTED]</recipient>
</match> <match class="RecipientIs">
<recipient>[EMAIL PROTECTED]</recipient>
</match> <match class="RecipientIs">
<recipient>[EMAIL PROTECTED]</recipient>
</match>
<mailet class="ForwardMail">
<!-- neccessary options -->
</mailet>
<mailet class="ToStage">
<stage>finalStage</stage>
</mailet>
</stage>
<stage name="evenMorePossiblities"
config="jdbc://tableofMailetConfigObjects"/>
This is just a rough picture of how things could begin to look. I've
tried to show some useful features added with this terminology. I'd
like to run with this and maybe begin it some time next week. Any thoughts?
>
> This is slightly more verbose in the config but less confusing, I think.
> It also allows log messages to specify exactly which use of a mailet or
> matcher is reporting something.
> and, it gives us more flexibility going forward, in case, e.g. someone
> comes up with boolean matchers or multiple mailets per match.
exactly! This is what I tried to demonstrate above :-)
> One factor is getting James to restart - or more accurately reconfigure
> the spool manager block. This should be handled by a Phoenix service but
> I'm not sure how.
Nor am I. We will need to talk to work with the Phoenix developers on
this one, because it is a very important and powerful feature.
>
> The second is that Avalon/ Phoenix has (I think) a Camelot system for
> containers so that mailets could be like WARs in a servlet container.
> That could be cool, but might be a lot of work.
I definitely would be cool MARs :) anyway I don't know anything about
the Camelot system (yet) but I don't think that this would be too
dificult to add support for. With the introduction to stages and
external configurations it becomes even easier. All a Meta file would
need to do is point to its Mailet Package path(s) and its Stage config
file(s) and maybe some other useful information.
One thing that comes to mind and needs to be worked out though
(eventually, for now its one day at a time) is Namespacing. It will
quickly become a neccessity in a dynamic system like this. Just
something to think about.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
