Re: Avalon dependance in mailets

[Kenny Smith]

Hi Jason,

I don't know enough technically about about java.util.logging and log4j to really give a blow by blow of which is better. I've used both, they both worked fine, both seemed easy to use. I think I like log4j better, but that's not really a good enough reason for choosing one over the other. I would probably lean towards log4j simply because it's another apache product. Any support we can give is good support. :)

Kenny

Jason Webb wrote:

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]>