james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@apache.org>
Subject Re: Finer Logging Control for Mailets/Matchers
Date Mon, 10 Jun 2002 09:54:02 GMT
From: "Danny Angus" <danny@apache.org>

> > Looking at the servlet spec, I see that Servlet has no logging in.
> > http://jakarta.apache.org/tomcat/tomcat-4.0-doc/servletapi/javax/s
> > ervlet/Ser
> > vlet.html
> >
> > ServletContext, on the other hand, has it
> > http://jakarta.apache.org/tomcat/tomcat-4.0-doc/servletapi/javax/s
> > ervlet/Ser
> > vletContext.html#log(java.lang.String,%20java.lang.Throwable)
> >
> > ServletContext is the object that is used to communicate with the
> > container.
>
>
> And likewise Mailet uses MailetContext to provide services whos
> implementation depends upon the container architecture.
>
> In fact the servlet API provides identical (and with no external
> dependancies) logging, basic "append a string" to the servers log in an
> implementation specific way, that the current Mailet API does, and I tend
to
> the opinion that this is enough.

If it's enough, then why do *all* frameworks based on the servlet Spec
simply not use it?

> Why?
> Well inspite of all that has been said I believe that:
> 1/ the mailet API should have as few external dependancies as possible
> preferable none.

Also of the java.lang? Of java.util?
You must have a dependency; the important thing is that that dependency is
the basic stable common block on which you build.

Java API is one.
For Apache Java servers, it's Avalon Framework.

> 2/ the basic logging specified by Mailet1.2 (current) and Servlet2+ is
> enough for simple operations, it removes the need for developers building
> trivial functionality to factor in their own logging.
> 3/ it does not preclude developers of complex functionality from building
or
> using any other logging framework.

If one needs "trivial" functionality, he'll use System.err.
If not, he needs a robust logging system.

> The only change I would make would be to include in the MailetContext an
> r.o. attribute called "logsRoot" which would hold the path to the
containers
> suggested location for context specific log files, eg ../logs or
> ../apps/appname/logs.

This is what has been done in the Cocoon context object and is't *B*a*a*a*d.
We got burt on this, since it's a big fat HOLE in your framework-api.
An Api must abstract, not make you work with underlying implementations.
For example, the xml DOM API left open the use of implementation-dictated
methods for creating parsers and parsing.
What we got were programs that needed a specific parser.
Jaxp solved this, but it was a real PITA to convert all legacy code.

I also don't see why making the Mailet API depend on the Avalon Framework
API is a bad idea.
In fact, I *strongly* think that all Apache Java server APIs should depend
on and use Avalon Framework.

Avalon framework is made to keep all the lifecycle methods of server Apis in
a single package.
If you don't use them, if you don't want dependency from them, well, Avalon
framework could simply die.

I see you haven't replied to my other points, so I assume they were correct.

Any solid technical reason for not using Avalon framework API?
I yet have to see one.

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


Mime
View raw message