James debugging

[Serge Knystautas]

Debugging, well actually testing, is very difficult for mailets and matchers right now. I remember we had talked about a development kit at one point, but I thought I'd offer a couple of suggestions.

- Have RemoteDelivery take a "debug" mode setting, and if on it would log what it would have done (deliver this message to these addresses), make no attempt to deliver it though, and then delete it.

- Create a collection of test messages (odd subjects, headers, attachments, whatever) that you can run against your matcher or mailet and check that there aren't unexpected exceptions.

- I'm not sure exactly how to get this working in a JUnit framework, but it would be nice to have a way to unit test mailets and matchers against a standard (and extendable) list of rfc822 messages. So maybe we have 10 or 15 standard messages that shouldn't make the mailet barf, and then let the user add additional messages. Maybe also have the framework specify results for each of these messages, but that's a tougher test to setup.

I know Danny is working on mailet classloading which will make it much easier, but to the extent we could have some other facilities to debug mail applications, I think that'd be great. Ideally these could run offline with ant, but also within James... so many developers now are used to changing a servlet or template and pulling up a webpage to test, but this is much more difficult to do with mail-based apps.

Just a late night tangent that hopefully might spark some ideas and interest.

--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com/



--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>