I'm sorry I haven't been responsive to any of the lists. I'm very busy with work and a book project at the moment, but hopefully I'll have some time later this week to at least respond. I do have a few items of news:
Bad news: 1. File repositories will not be upward compatible from 1.2.1 to 2.0 While the James code kept the file formats the same between versions, we upgraded Avalon and that code changed naming conventions for files. :( If you copy the file-pair in a 1.2.1 repository into a 2.0 repository, Avalon never sees that file because it's not named correctly. I would hope it shouldn't be very hard to write a mail repository migration tool (to move from old avalon file to new avalon file or DB or whatever) if anybody wanted to write that and contribute, that'd be great. 2. Avalon DB connection pooling not ready Unfortunately Avalon's excalibur db pooling code isn't ready for heavy use. A minor problem is that it automatically kills a connection every 15 uses (not configurable), but more importantly, it doesn't support blocking. When you hit the max number of connections, it throws RuntimeExceptions each connection request, until there's one available again. In the DB mail repository and the mailets that use the db conn pool, I've wrapped calls to the excalibur db pool in a very crude loop to get a connection, but it's kind of a showstopper. 3. Avalon file (stream-based) repository still not quite stable Even with my code to make sure both files exist, I've found I still occasionally get 0-byte files created on occasion. This has particularly nasty effects because the spool seems unable to delete the file in these cases, and throttles the server retrying the same bogus file. I guess I'll add code to catch this situation, but I perhaps I need to create a timer block that will prevent a message being unlocked until delete operations are complete. This will hurt performance, although in theory you can just boost the number of threads to compensate. Like I said, I'll try to respond to each person's emails to the list later this week. Good news is: 1. We've got classloader plans set, so I'll be able to create a app/james/classes directory where you can stick mailets and matchers, so you don't need to rebuild your James dist to use custom mailets/matcher. Might even go ahead and detect .java files and try to compile them, although there's not an easy way to output compilation problems. Also it will make it much easier to support reloading. In fact, I'm thinking about moving the mailet/matcher part of the code into a separate .xml file (since it's rather independent of the other system-level configuration), and then I can check for changes to that file or the .java/.class files. 2. The code is mostly stable. :) Aside from the fact that neither file nor db mail repository works 100%. :) Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
