I tweaked the API a bit more and have put the final 1.0 (hopefully) mailet javadoc out at http://www.lokitech.com/~sergek/mailetdocs/ The biggest problem I faced was the message routing within the mailet container. We'd talked about this and never quite reached a decision anyone was thrilled about (from what I remember). The specific problem I had was that in the existing code, the routing was handled by specialized mailets that were extremely Avalon dependent and intermixed. By enforcing that mailets are independent of Avalon, I had to make the processor class part of the JAMES/Avalon framework and no longer make it a mailet. I don't know if I'm very thrilled with this approach, but I think it works rather well and is relatively close to what Federico had implemented (but falls short of I think his ultimate goal of custom processors). The mailet container has a collection of linear processors. A processor is a series of mailet/matcher pairs. The following is a simple example of a processor with 2 mailet/matcher pairs: <processor name="try"> <mailet match="RecipientIsLocal" class="LocalDelivery"> </mailet> <mailet match="All" class="RemoteDelivery"> <delayTime>21600000</delayTime> <maxRetries>5</maxRetries> </mailet> </processor> There are two key or "reserved" processors, namely "root" and "error". When a mailet container processes an email message, it will send the Mail object through one of these processors, checking each matcher, and if met, has the paired mailet service the Mail object. (the mailet container will also create two instances of the message and split the recipient list across the two instances if the matcher only selects a subset of the recipient list. it is actually planned and described in the API that a matcher could return multiple subsets of the recipient list to have the mailet container create three or more instances, each with a subset of the original recipient list). The mailet container determines which processor to run on based on the Mail object's *state*. The MailetContext object lets a mailet writers send messages to the top of a queue by specifying the optional parameter of state in the sendMail method. If you understand me so far, it will hopefully be clear why root and error are "reserved" processors (meaning, you must have them defined). Incoming messages are handled by the root processor, and if there are any errors, the mailet container sends them to the error processor. In the default configuration, the error processor stores the mail object to an error repository, but an administrator could have the mailet container configured to also send a notification to the postmaster, or whatever other desired behavior on error conditions. Between the various matchers and the provided ToProcessor mailet, an administrator can write custom logic that forks messages off onto specialized processing routes. I've got JAMES compiled, and it accepted an incoming message and remotely delivered it (which means it went across processors as the remote delivery was in the transport processor). I have a lot more to test, but I'm hoping we can put out a JAMES 1.2 this month as well as formally publish the mailet API. I have more writing to do to help explain what is going on and how to write custom mailets. The javadocs are much more complete and several of my long-winded emails have gone into these javadocs. Please send all feedback! Thanks! Will commit the code after a bit more testing this week. Serge Knystautas Loki Technologies http://www.lokitech.com/ ------------------------------------------------------------ To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/> Problems?: [EMAIL PROTECTED]
