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 Mail Attributes support added
Date Tue, 15 Jul 2003 11:47:08 GMT
I just committed to james-head and james-branch_2_1_fcs Soeren Hilmer's great contribution
that gives James "mail attribute" (or "message attribute") support.

Such support is immediately available just by restarting the server if James uses file based
repositories for inbox and spools, *even if there are messages in the queues*. 

For db based repositories instead the following steps must be done, depending on the following
three situations:

1) No "inbox" and no "spool" tables exist (no db repositories yet): just look for the string
"attributes support" in james/apps/james/conf/sqlResources.xml, uncomment/comment the sql
statements as described there and restart the server.

2) Both "inbox" and "spool" tables exist, but there are NO "old" messages to keep residing
in the repositories: do the comment/uncomment as said in (1) above, and either drop the tables
form the db and restart the server (if you haven't done any customisation) or add the "message_attributes"
column to both tables with *not null* and restart the server.

3) Both "inbox" and "spool" tables exist, but there ARE "old" messages to keep residing in
the repositories: do the comment/uncomment as said in (1) above, and add the "message_attributes"
column to both tables with *null* and restart the server. When, hours/days/weeks later all
pre-existing messages have been delivered, you may change the column in both tables from "null"
to "not null" if you wish.

I tested reasonably well with V2 both the file repositories scenario and the full db scenario,
using "mssql". Everything worked fine for me. My testings were done using the new mailets
and matcher coded by Soeren (also just committed by me), setting and checking attributes with
*string* values only; I don't anticipate any problem though with generic objects. But I invite
other people to do some testing.

I changed also the MailImpl.duplicate(String), to have it clone the original mail's "attribute"
HashMap into the new mail "attribute" field. This means that AbstractRedirect and subclasses
do propagate all mail attributes in the new messages they generate (also tested that). It
may become useful to add "set/removeAttribute" to AbstractRedirect: waiting for thoughts about
this point.

Finally, as a first use of this new functionality, I will very shortly add the ability to
check if a message comes from an SMTP AUTHenticated sender.

Also some kind of HasMailAttributeValue and HasMailAttributeValueRegex etc. matchers would
be nice to have. I may code them shortly, unless someone else does it.


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

View raw message