I think that the commons logging faction (Noel) have carried the day on this one, its pretty likely to be included.
> -----Original Message----- > From: Jason Webb [mailto:[EMAIL PROTECTED]] > Sent: 07 January 2003 15:52 > To: 'James Developers List'; [EMAIL PROTECTED] > Subject: RE: Avalon dependance in mailets > > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
