Sergei, > This all sounds very good! > Since am almost 70% done with my implementation including a > handler for DSN > style bounce messages and an Example DBProcessor. > I would suggest that I complete an initial prototype (Non mailet/matcher > approach) including rolling my own config and then I submit my code > somewhere for others to review. (This should help back some requirements > with a concrete example)
Yes, very good I agree. I have *just now* commited a revised James.java which provides an attribute "confDir" this attribute is a string path to ~james/appas/james/conf to allow you to pick up config files from there. I *haven't* tested it, excpet that it does compile. It should work, because it is exactly the same as the method used to get a path for the mailet/matcher classloaders, which do work. > One reason for this is that I guess it will still be a little while before > the new Mailet API is usable. As the new Mailet API starts to > develop we can > start migrating my code to the new mailet/matcher API with the enhanced > features and maybe discover some other requirements. Yep. > 1. Did we come to a conclusion on how to handle DB connections in Mailets? > Is the mailet responsable, is the MailetContext going to provide > for this or > is it optional based on the MailetContext implementation? The general feeling seemed to be that the the mailets should be responsible, at least for now. I suspect we may end up with "hasDBProvider()" and "getDBProvider()" so that DB provision is optional but allowed for containers. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
