Well, this seems like a more complicated, but equally more useful approach.
So, I figure, I implement a transport. This transport spools MimeMessages into the filesystem. Upon spooling, it checks for a delivery thread. If one doesn't exist, it creates one. The delivery thread then looks for any spooled messages, and if it finds any it attempts to deliver them using suns smtp transport. Any it delivers it deletes. Any failures it does nothing. Once it reaches the end of the spool, it checks for spooled messages. If it finds any, it sleeps for X minutes, and repeats process. If spool is empty, it ends. Sound about right? Looking through the JavaMail docs, it seems the smtp settings are included in the MimeMail via session in Message. Now I'm guessing that session wont be stored if I use the writeTo method. So, the mail server config used for sending the messages will be lost? I guess the delivery thread could be handed the Session settings from the first email that it attempts to deliver. This would mean that after a failure, it could not start delivery until a messages is injected into the spool. Another question: When I send mail, I am assuming that I will have to tell Session to use a different transport (going to mean messing with commons-sandbox-email because this is fixed to smtp). If I use the same session for sending mails, then I guess I will have to revert to smtp. Any thoughts? Daniel. > -----Original Message----- > From: Serge Knystautas [mailto:[EMAIL PROTECTED] > Sent: 24 May 2004 17:39 > To: James Users List > Subject: Re: Integration into Tomcat > > > Daniel Perry wrote: > > My favoured option is to write a struts plug-in, which uses a simple > > database table to queue messages (reliable) or a vector (less > reliable but > > simpler), and implements an inject method, and this causes a > thread to be > > started if no thread exists that deals with delivery. This thread > > periodically find any messages, tries to send them, and if successful > > deletes them. At the end of it's attempts, if the queue is empty, it > > finishes, otherwise it sleeps, and starts again. > > My suggestion is to implement a JavaMail Transport. Have this transport > use the existing SMTP transport, and if the delivery fails, spool > messages to the local file system. A thread will also need to run to > check that spool and retry indefinitely. > > This approach is very easy to plugin to a number of environments, I > would use disk over a DB since it is the easiest way to remove any > remote system dependencies, and can still survive JVM crashes and > restarts. Reading and writing MimeMessage to disk is very easy, too. > > I would be very interested in this since I've been meaning to write > something like for a while, but have about 20 of these projects and 0 > time. :( > > -- > Serge Knystautas > President > Lokitech >> software . strategy . design >> http://www.lokitech.com > p. 301.656.5501 > e. [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
