james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: On match/mailet exception handler (was in Separating internal errors from addressing errors in config.xml)
Date Tue, 10 Jun 2003 17:19:47 GMT
> I have in the past felt the need of having a richer way
> to interact with matchers than just through the
> condition string, using instead child elements as with
> mailets.

This has been a frequent area of discussion.  For James v3, there will be a
change.  See
http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3/MailetConfiguration for
some proposals.  You should be aware that there is little support for
Proposal #2.  Regardless, we would simply add an "onException" attribute to
the matcher element.

Also, a JNDI context could be used to provide information to matchers and

FWIW, the example in proposal #1 shows multiple matchers.  I'm actually not
sure how Danny has that in mind to work.  I don't know if they are parallel
or serial, nor if the set operation (matchers don't return boolean, they
return recipient sets) is a union or an intersection.

> I agree on switching to attributes.


> I don't know how to access <mailet> attributes. I can dig around the code
> but if you could give me a hint ... ;-)

Look in the initialize code for the spool manager, which is responsible for
loading the configuration.  There would need to be some internal changes
between the spool manager and the processor.

I probably can't help you much right now.  I had a SCSI drive fail on a
server, and dealing with that will probably consume me for a little while.
I've got the server running again, but I need to get a new server into

> I think that the feature we are discussing is totally transparent
> and backwards compatible, as defaults to the current behaviour.

I agree.  But when we expose a new configuration option, we want to make
sure that we do it in a way that we want to support for a while.  :-)

> Regarding what to do about per-recipient exceptions, instead of
> exceptions, I agree that we may handle it better in the future.

Something to put on the TODO list.  :-)

> To avoid future backward compatibility in configuration files, we can
>	matchException="[matchall|nomatch|error|aProcessorName]",
> in the future
>	matchException="[match|matchall|nomatch|error|aProcessorName]"

I don't believe that we need to make that change.  The exception, itself,
would provide that information.  Depending upon the type of exception, it
will either require matchall or it would provide information on individual

Please note that ERROR *is* a processor name.  It is a required processor by
that name.

> please do commit for me now the patch to AbstractRedirect
> as I am doing small things here and there, and I would
> prefer not having a too big patch accumulating different
> things.

Under normal circustances, I'd be happy to do it.  If I can, I will.  But
right now I have a server that I must attend to with some urgency.

	--- Noel

To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

View raw message