"Stanley,Michael P." wrote:
>
> > 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?
Sounds great - go for it.
Check out the package org.apache.avalon.excalibur.pipeline, its an easy
way to build pipelines of stages where a stage can be a pipeline. (Gosh,
someone must have thought of this before ... :-) )
>
> >
> > 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.
Agreed,
>
> >
> > 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.
I think this is the step after stages.
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
