james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrei Ivanov" <my...@surfeu.fi>
Subject Re: [Mailet API] Logging Proposal
Date Mon, 10 Jun 2002 22:14:10 GMT
I think there is still principal question which has to be addressed first.
The question is: will Mailet be Avalon dependant or not?
If Mailet is clean from Avalon then logging can be removed from Mailet API,
but if Mailets will be Avalonized then logging must (more precisely may) be
in API. Before this is decided no further speculations make sense.
I don't see anything against Avalonization of Mailets.
What is the bottom line of this discussion since James runs on the top of
Phoenix and Phoenix is on the top of Avalon? What is still not Avalonized in
James (like Mailet API) shall be Avalonized, or... whole James has to be
rewritten from ground up to keep it consistent with something else than
Avalon...
Andrei


----- Original Message -----
From: "Danny Angus" <danny@apache.org>
To: "James Developers List" <james-dev@jakarta.apache.org>
Sent: Tuesday, June 11, 2002 12:50 AM
Subject: RE: [Mailet API] Logging Proposal


> > The downside of (2) is that since logging, etc... are *always*
> > needed, every
> > implementor will put in his, and you can say goodbye to
interoperability.
>
> Ok, this is just Not True.
>
> Interoperability will be provided by the API, logging won't affect this.
>
> Any mailet application built according to the API and in spirit with it,
> according to the specification document as well as the code, will be
> interoperable with any container similarly built and any other
application.
>
> Logging is a "leaf" on the tree of dependance, I can see how other
services,
> such as repository or spool providers need to be controled in order to
> ensure interoperability, being "nodes" on that tree.
> The solution to providing logging is that the mailet application developer
> distributes their preferred logging classes with their application,
because
> in that situation interoperability is not compromised, the central purpose
> of the API is still served in spirit and in detail.
> There must be zillions of servlet applications that provide 100% of the
> logging service they require, and still comply with the API.
>
> I'm actually coming to the conclusion that providing logging in the API
> would make logging more cumbersome for sophisticated users, over
engineered
> for trivial uses and discourage many users from making their own
> architectural decison on a matter which is of *no* relevance to us.
>
> I'd like to know why anyone would expect sophistcated logging service to
be
> provided by the API, and what stories or use cases they can advance to
> support this.
>
> d.
>
>
> --
> 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