cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT C2]: Logging information
Date Mon, 02 Jul 2001 14:47:36 GMT
Sylvain Wallez wrote:
> 
> Berin Loritsch a écrit :
> >
> > giacomo wrote:
> > >
> > > On Wed, 27 Jun 2001, Carsten Ziegeler wrote:
> > >
> > > > Hi C2ers,
> > > >
> > > > what do you think about enhancing the information logged to the
> > > > cocoon.log?
> > > > For debugging etc. it would help to have a better formatted
> > > > time information, the current url request perhaps the current
> > > > ip address of the client etc.
> > > > So I would suggest to pass the current environment/objectModel
> > > > to the logging methods and they can extract everything they
> > > > need from it and log it.
> > >
> > > That wont work. You cannot extend the logging methods. You can write a
> > > custom LogTarget. We have solved such things by having a LogTarget as a
> > > Avalon Component which is put into work after the ComponentManager has
> > > been initialized.  But this only works for Configuration stuff. As the
> > > Environment/objectModel are request dependant (not thread safe) but the
> > > LogTarget is/should be ThreadSafe you have a problem.
> > >
> > > The other way is (IIRC) some contextStack you can push things upon and
> > > have your LogTarget pop it off there. But also I don't know how this
> > > works in a multi threaded environment like a Servlet.
> >
> > Whenever I get the opportunity, I want to augment the ExcaliburComponentManager
> > to define log targets and such.  That way we can have multiple files, etc.
> > to split all the info into.
> 
> Will you do it using additional attributes on the configuration element,
> like for the pool ? If so, we may end up with a lot of
> ComponentManager-related attributes whose name may conflict with the
> component's own attributes names.

No.  I will do it with logger specific elements.  There will be a core
logger, and the different "categories"/"channels" will be specified.  The
only additional attribute might be the log-category so that the Component
is given the logger in question.  The other alternative is to write your
Components to get the logger for child categories.  That way you can override
the targets later.

> I know Avalon configuration isn't namespace-aware, but it could be
> useful to distinguish infrastructure-related attributes from component
> attributes at least by the namespace prefix ("avalon:" or "excalibur:").

I believe the way it works now is that "avalon:foo" is treated as a unique
name.  (It is not read as "foo" but as "avalon:foo").

> (RT) Going further, the Avalon configuration could be extended with
> namespace-aware methods to allow a clean separation of these concerns.

That is the eventual idea.  The application is more difficult though....
Mime
View raw message