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. Vincenzo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
