> I thought I read about a simple log(String) method... > I agree that the Mailet API should not legislate on logging, and > delegate (in our case) to the Avalon Apis, that are made just to do this > "legislation".
Put it this way; The void log(String message) method exists in Mailet 1.2 and in Servlet 2+, it is heavily used in James mailets, I don't feel so stongly about it being inapropriate that I would deprecate it, but if I was starting from scratch I would probably omit it. > Ok, so let me push this discussion a bit further. > The Mailet API is basically the Mailet interface(s) and the Context. > Most of the problems with defining a server api come from the definition > of the container in fact, with regards to common services: logging, > getting other services, Context, etc. Yes, I agree, I also believe that it should be a goal to make the Mailet API completely self referential, and that a goal isn't necessarily pointless just because it isn't ever achieved. However there remains the issue of exacly those two situations you mention: > MailetConfig: Configuration-Configurable > MailContext: Context-Contextualizable It seems reasonable to consider avalon.framework for this but I'm going to examine the whole of avalon.framework (a.f.) quite closely before I commit myself, amongst other things I need is some indications of the maturity of a.f (rate and impact of change) an understanding of its evolution, and how that would effect Mailet in the future. In particular if Mailet 2 is a success and generates a lot of Mailet2 applications I don't want new mailet 2 container implementations to have to use a stored snapshot of a.f. made sometime this month, nor do I want maintenance of Mailet 2 to be dominated by changes driven in by a.f. I'm not singling out a.f for harsh treatment I would apply the same criteria to any proposed dependancy including javax.mail, but in fact we are well aware of the strengths and weaknesses of JavaMail, the opportunity cost of not using it, and its fitness for the purpose to which we intend to put it. Beyond that I think it is not unreasonable to have dependancies within Mailet that are invisible to Mailet writers, and don't represent significant burden on container implementors. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
