james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: Avalon dependance in mailets
Date Tue, 07 Jan 2003 16:12:36 GMT
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:jw@inovem.com]
> Sent: 07 January 2003 15:52
> To: 'James Developers List'; nicolaken@apache.org
> 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:nicolaken@apache.org]
> > 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                   nicolaken@apache.org
> >              - verba volant, scripta manent -
> >     (discussions get forgotten, just code remains)
> > ---------------------------------------------------------------------
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:james-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <mailto:james-dev-help@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message