tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arieh Markel <Arieh.Mar...@Central.Sun.COM>
Subject Re: possible Tomcat 3.1 issues
Date Thu, 06 Apr 2000 14:42:35 GMT

> Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
> X-No-Archive: yes
> list-help: <mailto:tomcat-dev-help@jakarta.apache.org>
> list-unsubscribe: <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> list-post: <mailto:tomcat-dev@jakarta.apache.org>
> Delivered-To: mailing list tomcat-dev@jakarta.apache.org
> From: rubys@us.ibm.com
> X-Lotus-FromDomain: IBMUS
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: possible Tomcat 3.1 issues
> Content-Disposition: inline
> X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
> 
> 
> 
> > The idea is that there should be a logger per significant subsystem and
> > each subsystem can generate a message that can be XML wrapped OR can
> > inidicate to the logger that it will format its own messages and the
> > logger shouldn't wrap them in <XML>...</XML>.
> 
> I had an extensive off-line conversation with Costin about this.  My
> position is that it is rather presumptuous for an embeddable component to
> predetermine the formatting of log entries.  The core code should determine
> what data needs to be logged (either with name/value pairs or
> positionally), and leave it up to the logging subsystem to determine how to
> format it.  Simply put, some hosts may already have their own conventions
> defined.
> 
> > <tongue>
> >   <in>
> >    <cheek>
> 
> Cool!  I really like the fact that the inter-working relationships and tone
> of notes has improved much since days which lead up to the previous (3.0)
> release.  When people can poke fun at each other in e-mail and it is taken
> in the spirit intended, as a team we must be doing something right.
> 
> > The reasoning behind XML-logs is that XML is cool :-) I believe
> > perl/sed/awk based log processing is more than enough but these days we
> > want to have all kinds of transformations declaratively specified that
> > postprocess these XML logs to all kinds of cool things -- for example an
> > MS Word document which will then be at its peak of human readability :-)
> 
> +1 to implementing a logger which formats the data as XML.  -0.6 to putting
> the XML directly into the core.


Just a follow-up on the XML-formatted log thread.

I am not sure if a dtd for what the log messages are composed exist.

However, it appears to me that if we want the solution to be comprehensive (i.e. 
to allow development of XML-logs processors that could convert the 'raw' XML to
some other format - Apache log format comes to mind), we need to agree
on what that dtd needs to be composed of.

Among the elements that I can foresee in such a dtd:

	time stamp
	system source
	subsystem source
	message content

Message content can/has to be dependent on the system/subsystem combination.


Arieh

> 
> - Sam Ruby
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

--
 Arieh Markel		                Sun Microsystems Inc.
 Network Storage                        500 Eldorado Blvd. MS UBRM11-194
 e-mail: arieh.markel@sun.COM           Broomfield, CO 80021
 Let's go Panthers !!!!                 Phone: (303) 272-8547 x78547
 (e-mail me with subject SEND PUBLIC KEY to get public key)


Mime
View raw message