Dan, On 17/11/05, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: > Danny Angus wrote: > > Dan Debrunner wrote:
> Thanks for all the info. At ApacheCon Europe I discussed with Noel (in > his presentation) some of the possiblilities of integrating Derby and > James, the first step would be Derby as a data store for James. Yeah, sadly I missed you there, but I spoke to Noel about the same things, in fact I'd already hacked James to use derby embedded after using derby at work to embed in a number of log-file analysis tools so I knew it would work. (It is so cool to be able to use SQL to analyse logfiles by the way) > I've downloaded James source and compiled it, and run it, though I > haven't yet tested sending e-mail to/through it. I briefly looked around > the James site but didn't see any instructions on how to set it up for > Derby, any pointers would be appreciated. There sadly there won't be any, but you can look at the config.xml database config parts, and sqlResources.xml for the sql dialect stuff, James can be a bit of a pain to understand at first, I'm not knocking it but the IoC/Phoenix stuff sadly does a pretty good job of obscuring it from casual understanding. > Subsequent possible integrations are James running within Derby to > provide better e-mail support from procedures, functions and triggers, > such as e-mail spooling. That sounds interesting. Our long-term architecture plan is to make James container agnostic, and prepare deployments by wrapping James classes in classes which can map container specific lifecycle events & services onto James' API. We also like the idea that individual parts of james could be deployed seperately and storage/spooling is certainly one area that would make sense from an operational point of view. Using derby with some parts of James embedded in in in a distributed James installation would result in an n-tier mail system in which the datastores are self-contained and "smart". Hmm... James wouldn't need to manage them, they could manage themselves, exposing a couple of very simple services. (perhaps I should say DBA's would manage them ;-) being able to using triggers with spools would be superb, you could use the triggers to notify a sleeping dequeue process that it is time to wake up, this would eliminate polling and the delays caused by inappropriate sleep-times, it might mean that we'd need to change the process that uses the spool to accept pushed notifications, but I don't think that would be beyond us. > Then I wonder if transactional e-mail is > possible, send an e-mail from a trigger, but if the transaction > subsequently rolls back, don't send the e-mail. This is 100% possible already if derby manages the spool, even without embedding either thing in the other because it is OK to insert records directly into the spool tables already. You just have to be careful to set appropriate values and validate the data of course, doing this in a transaction would indeed cancel the message on rollback. If you get the chance to try it the easy way to know what values to use is to send a regular mail through James and query the table to see what it looks like when it is in the spool, the important bits (the routing and status stuff) are just varchars with text strings, normalising them into look-up data would allow validation in the db, but we'd have to do it for all our supported dialects and we've got little enough time between us to do the interesting things. Two very nice ideas, now where did I put my spare time... :-) d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
