james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincenzo Gianferrari Pini" <vincenzo.gianferrarip...@praxis.it>
Subject RE: On match/mailet exception handler (was in Separating internal errors from addressing errors in config.xml)
Date Tue, 10 Jun 2003 16:12:19 GMT
Noel,

> Please see my reply from a few minutes ago suggesting different syntax.
> With moving the configuration to an attribute on mailet, I don't have a
> problem with it.  So far no comments from Danny, Serge or anyone else.

I have taken the approach of using child elements for two reasons.

The first is that 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.
For instance, when I modified Cesar Bonadio's antivirus matcher, I felt the <mailet match="..."
...> too "ugly" because there were so many parameters to pass. But now I'm more "aesthetically"
preferring the way it is now (matchers only accessing the condition strings, mailets accessing
child elements), because is more adherent to an if (condition) then {block} appearance. I
have in mind infact change the IsInfected matcher to a VirusScan mailet followed by a "HasHeader=X-IsInfected"
check: it is more flexible to code a config.xml that way, and cleaner to understand. So I
agree on switching to attributes.

The second reason is that I saw immediately how to code it in LinearProcessor, while I don't
know how to access <mailet> attributes. I can dig around the code, but if you could
give me a hint ... ;-)

Wait a moment, I just found MailetContext.getAttribute(String). Is it that one? No, it seems
to be global :-( 

> 
> We can operate on the idea of a "lazy consensus", which means it is OK
> unless there is an objection.  However, there are two things I would take
> into account:
> 
>  - Changes to branch_2_1_fcs have to be carefully considered.
>    That is our stable branch.  We should make every effort to
>    keep it entirely stable.
> 
>  - Changes to the public interfaces should also be carefully
>    considered, since they are the hardest to change after
>    people start using them.
> 

I think that the feature we are discussing is totally transparent and backwards compatible,
as defaults to the current behaviour. It is instead important not to change the try/catch
behaviour of existing matchers/mailets (other than the new AttachmentFileNameIs, that simply
should behave like HontvariJoszef wants).

Regarding what to do about per-recipient exceptions, instead of per-message exceptions, I
agree that we may handle it better in the future. To avoid future backward compatibility in
configuration files, we can change

	matchException="[match|nomatch|error|aProcessorName]"

to

	matchException="[matchall|nomatch|error|aProcessorName]",

and in the future to

	matchException="[match|matchall|nomatch|error|aProcessorName]"

when we will hopefully support specific per-recipient exceptions. This way whoever uses this
new feature in config.xml knows that matchall matches per message.

> I have not committed your patches.  You'll have your account shortly, and
> should be able to do so directly.  :-)

Great, but 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.

Vincenzo


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


Mime
View raw message