Re: [RT C2]: Logging information

[Berin Loritsch <bl...@apache.org>]

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.

Re: [RT C2]: Logging information

[Berin Loritsch <bl...@apache.org>]

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

Re: [RT C2]: Logging information

[Sylvain Wallez <sy...@anyware-tech.com>]

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.

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:").

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

My .02 euro.
-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [RT C2]: Logging information

[giacomo <gi...@apache.org>]

On Mon, 2 Jul 2001, Berin Loritsch wrote:

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

I think you should read/study the LogKit. There is everything you need
to do that. You don't have/want to augment the ComponentManager with
thing that doesn't belong to it. It's not the problem defining a
LogTarget as a component. It's a problem to change the LogTarget at the
right moment. And since it is not the responsability of the
componentmanager to setup and define a Logger you'll have to do it
somewhere in the normal code (outsite a component).

Giacomo


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org