Logging is an interesting one. As far as mailet developers are concerned I think logging should be provided (by the container?). Everyone needs to log something at some time, but DB access is not always required. My only real problem with the current system is it's lack of fine control over the logging. If James 3.0 will go to JDK 1.4 we could use the builtin logging there. I'm not going to get into a logging system war here either :)
-- Jason > -----Original Message----- > From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > Sent: 07 January 2003 15:29 > To: James Developers List > Subject: Re: Avalon dependance in mailets > > > > Danny Angus wrote: > > > > Nicola Ken Barozzi wrote: > > > >>This makes me think... > > > > Its a thought provoking topic! > > I wrote another reply to this mail, but by the end of it > I'd changed > > my mind, here's version 2 :-) > > > >>Essentially the Mailet API won't thus provide portability > of mailets > >>between servers, just a common API, right? > > > > Actually the work I've been doing is supposed to this so .. > > > >>Meaning that I cannot simply get a mailet written from James and > >>simply pop it into XMailServer and hope it to run, right? > > > > That is not correct *unless* your mailet uses Avalon via > James to get > > database connections, in which case your mailet will not be > portable. > > In all other cases it will be. > > Errr, what about logging? I mean that every service that a > mailet uses > that are not part of the mailet API can potentially be a portability > breaker. > > Not that I see this as a bad thing, in fact I start to understand the > reasoning behind a simple API. > > >>This could be a strength and a weekness. > >>Strength because it's easier to learn, implement and to > keep focused > >>in development . Weekness because it's not made to make completely > >>portable mailets. > >> > >>So what about doing a Mailet spec as defined above and define an > >>additional Avalon Mailet profile, that James could use, to define > >>other aspects like logging, get db connections, etc? > > > > We discussed this a while ago, and I argued that we should keep the > > API as clean of dependancies as we can. The db issue is really only > > relevant for the portability of James mailets, it is > possible to write > > portable db access mailets by managing connections independantly of > > James. > > Yup. > > > If what you are suggesting is that we should build a portable 100% > > Mailet API compliant framework which would itself manage these > > services for any mailets written to use it then I agree. > > :-) > > Of course, I see this Mailet API compliant framework as > > Mailet API + Avalon API > > IMHO if we say that James mailets are just Avalon Components that use > Mailet API, then there is no need to define anything else. > > > It would have to be compact, I have a vision of the Mailet > API being > > used in client software for mail filtering and similar tasks. > > Yes. > > > It would also have to be deployable either as a runtime > dependance or > > as a simple wrapper for single mailets. > > Cool. > > > One further option might be to include processors in the API > > specification and create a distributable processor which > could offer > > services to the mailets it contained. > > > > At the end of the day, though, if we assume that not all mailet > > containers will be capable of providing JDBC connectivity for some > > reason then mailets using JDBC will have their portability > restricted > > no matter what we do. > > Yes, that's what I came to think too. > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- > > > -- > To unsubscribe, e-mail: > <mailto:james-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
