cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alejandro P. Revilla" <>
Subject Re: C2 Logging
Date Thu, 25 May 2000 16:04:25 GMT
> > > Stefano Mazzocchi wrote
> > > 4) Internal logging.
> > 
> > > Well, this is in the Cocoon1 todo list but I'll implement it in
> > > Cocoon2... I saw the IBM Log4j package and sounds pretty good. Another
> > > option would be to use Avalon's Omero... we'll see.
> > 
> > > Anyway, internal logging will be a must when the pipeline will be in
> > > place.
> > 
> > This is an old message, but I'm curious if there are still plans for logging
> > in C2. I would love to see a logging facility that is robust enough to
> > capture crital errors for alerts(email/page) and monitor informational/debug
> > messages via a terminal. Lots of possibilities here, but something even
> > minimal for critical errors would seem like a must?
> whatever it is, it oughta use ibm's log4j package. it kicks.
I've developed a very simple and extensible logger subsystem
for my little project (yet another logger subsystem...)

It has just three main classes. LogSource, Logger and LogEvent
and a few LogListeners.

You associate a "realm" (so you can filter events) to your LogSource 
and associate LogListeners to your Loggers. It comes with three 
standard LogListeners (SimpleLogListener dumps to PrintStream,
RotateLogListener writes to a set of files and perform rotations
and OperatorLogListeners batches e-mails with selected 
events at customizable intervals).

Output is XML _like_, all log messages are at least encapsulated
by a "<log></log>" and a custom message tag specified at 
LogEvent creation. 


<log realm="your-realm" at="Wed May 24 18:47:13 NDT 2000">
  Any text

    Exception StackTrace

and objects such as Exceptions, SQLExceptions, etc. gets
special treatment (i.e. getNestedException() gets called, 

It would be very easy to provide a LogListener that
would generate SAX events or change things to generate
SAX events out of LogEvent (source of the log message itself).

SyslogListeners that forward messages to Syslog
and even a log4j based LogListeners are easy to build
(hmm.. wrapper syndrome...:-).

Inspired by Cocoon's sitemap configuration, Logger currently
integrates with my QSP project by means of a xml configuration
file, something like this:

 <logger name="my-logger">
    <log-listener class="org.jpos.util.SimpleLogListener"/>
    <log-listener class="org.jpos.util.RotateLogListener">
      <property name="file" value="/var/log/authd.log" />
      <property name="window" value="86400" />
      <property name="copies" value="10" />

Adding a 'logger' attribute to ELEMENTS like 'filter', 'generator',
etc. to your cocoon.xconf file you would be able to assign different
loggers to your components (posibly on the fly).

You simply add objects to a LogEvent and then fire a 
Logger.log(yourEvent). Objects added to LogEvent may optionally
implement "Loggeable" interface (just a dump() method) and it's
dump method will get called instead of its toString() method.

I know there are many alternatives right now, I've develop this
little one some time ago, prior to log4j and Avalon's Omero 
availability but I still think it's usable and best of all, 
it can be easily adapted to our needs (and by the way, it's 
production quality, or at least I have it in production ;-) 
7x24 on some critical credit-card related systems).

If you want this code I would be glad to donate it to Cocoon
(you can rename package name, change license, whatever) and 
also help you to integrate it with existing code, 



View raw message