cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Burton" <ross.bur...@mail.com>
Subject Re: C2 Logging
Date Thu, 25 May 2000 16:06:00 GMT
> > 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?

I investigated logging in C2 recently, but stopped work due to two reasons:

1) I'm doing my final exams  :-(
2) design decisions about the architecture

I was thinking of creating a Logger component which is used just like all
other components in Cocoon 2.  However, as loggers often need to maintain a
complex state (i.e. a ServlerLogger needs to know the ServletContext) they
cannot simply be null-constructed and configured using the sitemap, as there
is no way to give the logger the context.  I hacked around this by
mutilating the Singleton pattern, keeping configuration in a static
variable.  The Servlet -> Cocoon 2 adapter class created a Logger and passes
it a ServletContext, which is stored.  Cocoon 2 was passed this logger in
the create() method, which is put in the component store as usual.  When
another component requested a logger from the component manager, it got
constructed, saw the static configuration and configured itself.  Although
this worked, it was very hacky and required a logger implementation to
handle this book-keeping itself.

My other idea was a LogProducer / LogConsumer pair of interfaces, which are
handled by the component manager.  C2 is a log consumer and a log producer,
in that it consumes log events from components and forwards them to the
logger being used, a log consumer.

I think the logging idea should be discussed now, just before the core gets
rewritten in light of the new and improved sitemap.  Good logging is
essential for good debugging!

Ross Burton


Mime
View raw message