james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Mailet Logging ==> Jakarta Commons (org.apache.commons.logging)
Date Tue, 01 Oct 2002 14:38:35 GMT
[This message merges to threads on logging]

> Tomcat and the servlet API you quote provide only for log(String)
> leaving any more sophisticated logging requirement to the discretion
> of servlet writers.

> As far as I'm concerned the logging of mailets should be an issue for
mailet
> developers, developers are free to use commons logging or anything else in
> their mailets, as is the case in the servlet API.

Oh, I get it!  Good idea.  We'll treat Mailets just like Servlets.

The Servlet API is part of J2EE.  The initial lack of standardized logging
resulted in unmanagable systems (first because of no logging APIS, then
because of too many logging APIs desparately trying to fix that problem),
but the Servlet API didn't need to be enhanced to fix things because it
isn't standalone -- it lives in the context of Java Logging, which is a
mandatory part of J2SE (java.util.logging, not javax.util.logging).  I have
been saying the same thing: the Mailet API doesn't need new methods, but the
mailet environment should include a common logging interface.  I had
suggested using Jakarta Commons, since James is a Jakarta project, and the
Jakarta Commons logging API is neutral, but your idea works fine.  Servlet
authors and administrators can count on Java Logging, which is (after all) a
de jure Java Standard, and you are saying that Mailets should be the same as
Servlets.

Good idea, Danny!  Because we all know that if we just tell every mailet
author to pick (or roll) their own mechanism, it leads to the kind of
unmanagable chaos that people are trying to clean up, so we certainly don't
mean to encourage that!  Your idea to use Java Logging takes care of that
problem.  Mailet authors can count on the presence of Java Logging, just
like Servlet authors, and James administrators get the control and
information that they need.

Ok, this could work.  We ignore the global configuration file, and have
James configure a default mailet logger from information in Jame's own
configuration files.  We can make a shared logger object available through
the MailetContext.  A mailet that supports the use of its own logger can be
configured through its <mailet> tag, which is probably not a good idea, but
at least provides the James admin with a common point of control.

If we want (perhaps for people porting code into a mailet), we could support
optional logging APIs by layering a Jakarta Commons logger or Avalon
Frameworks logger on Java Logging, but the standard interface will be Java
Logging.

This won't force people to upgrade to Java 1.4 in order to use James.  We
can use lumberjack (http://javalogging.sourceforge.net/) for Java 1.2+
environments.

	--- Noel


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