You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Jorge CAMPOS <Jo...@gemplus.com> on 2005/01/04 23:51:20 UTC

Avalon-Excalibur Logger

Hi!

I've modified the org.apache.avalon.framework.logger.Logger interface to add
a changeLevel method... I've also changed the implementations to support
this method... In this way the log level can be reset at runtime.

What do you think about the approach? I've speculated changing LoggerManager
instead, but since you can get a specific logger from the LoggerManager the
right place seemed to be Logger.

If it is OK, is it possible to post it somewhere for consideration towards
its inclusion in the framework?

Best regards

Jorge


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


RE: Avalon-Excalibur Logger

Posted by Jorge CAMPOS <Jo...@gemplus.com>.
I will take a look at JMX integration, but nevertheless I think reconfigure
support should be add to the container.

The multithreaded issue is up to the components, if a component implements
the reconfigurable interface, then it should do it in a proper way (as with
any other interface/contract).

Returning to the logger... reconfiguring the LoggerManager and giving new
Loggers to all components is not transparent for the components. It would be
the only way is you intend to switch loggers, but if you only want to change
the level (which is supported by most logging frameworks) it seems too
intrusive to me.

And yes! we want Fortress 2.0 ;) is the roadmap somewhere in the cyberspace?

Cheers

Jorge

-----Original Message-----
From: hammett [mailto:hammett@uol.com.br]
Sent: Wednesday, January 05, 2005 5:32 PM
To: Excalibur Developers List
Subject: Re: Avalon-Excalibur Logger


----- Original Message -----
From: "Jorge CAMPOS" <Jo...@gemplus.com>

> Please, tell me everything I'm looking for is already done and it's simply
> that I didn't searched enough ;-)

Sorry! :-)

You could use JMX to reconfigure the components instead of a reconfigure
lifecycle.
I'm not sure whether there is an integration between JMX and Fortress ready,
but it would be good to have one.
Another concern is how to reconfigure everything on a multithreaded
environment, your components should be prepared to deal with it, right?

On the logger issue, I think you should reconfigure the logger manager and
then give the components new loggers. What do you think?

All of this could find its home on Fortress 2, which is on the plans for a
while...

--

I'm looking forward to hearing from others members of Excalibur Team.

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett



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


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


Re: Avalon-Excalibur Logger

Posted by hammett <ha...@uol.com.br>.
----- Original Message ----- 
From: "Jorge CAMPOS" <Jo...@gemplus.com>

> Please, tell me everything I'm looking for is already done and it's simply
> that I didn't searched enough ;-)

Sorry! :-)

You could use JMX to reconfigure the components instead of a reconfigure 
lifecycle.
I'm not sure whether there is an integration between JMX and Fortress ready, 
but it would be good to have one.
Another concern is how to reconfigure everything on a multithreaded 
environment, your components should be prepared to deal with it, right?

On the logger issue, I think you should reconfigure the logger manager and 
then give the components new loggers. What do you think?

All of this could find its home on Fortress 2, which is on the plans for a 
while...

--

I'm looking forward to hearing from others members of Excalibur Team.

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett



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


RE: Avalon-Excalibur Logger

Posted by Jorge CAMPOS <Jo...@gemplus.com>.
Hi!

In our server sometimes we'd like to change the verbosity of the log in
runtime... It is not possible for us to restart the server on most cases.

I extend this to all the configuration. The log level reset is just one
part. We would like to add reconfiguration capabilities to Fortress.

AFAIK, there's no way to change the log level or reconfigure the
container/components (at least in Fortress) at runtime... so, that's why we
were thinking in these changes.

I know it should be tested a lot... but I think reconfiguration is something
really good to add to the container in order to support servers that could
have 99.9% or more uptime.

And regarding your last comment, the change will be in response of a
sysadmin request, not an event within the application.

Please, tell me everything I'm looking for is already done and it's simply
that I didn't searched enough ;-)

Cheers

Jorge

-----Original Message-----
From: hammett [mailto:hammett@uol.com.br]
Sent: Wednesday, January 05, 2005 4:08 PM
To: Excalibur Developers List
Subject: Re: Avalon-Excalibur Logger


Hi there!

I think you should step back and try to understand why you need something
like that at first hand.
It sounds like a very specific solution to a very specific problem. Can you
share with us why this is a requirement?

I imagine that even for direct users of, say, Log4j, changing the level in
respose to something is a rarely used approach.

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett


----- Original Message -----
From: "Jorge CAMPOS" <Jo...@gemplus.com>


>I see.
>
> As of now I've changed the implementations of Logger within framework (I
> saw
> some more in the containerkit module, I will change those too).
>
> Now I need to propagate the new level to the childLoggers. And if we stick
> to the Logger approach, this responsibility will belong to Logger. Another
> posibility could be changing the AbstractLogEnabled and LogEnabled to add
> a
> changeLogLevel method.



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


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


Re: Avalon-Excalibur Logger

Posted by hammett <ha...@uol.com.br>.
Hi there!

I think you should step back and try to understand why you need something 
like that at first hand.
It sounds like a very specific solution to a very specific problem. Can you 
share with us why this is a requirement?

I imagine that even for direct users of, say, Log4j, changing the level in 
respose to something is a rarely used approach.

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett


----- Original Message ----- 
From: "Jorge CAMPOS" <Jo...@gemplus.com>


>I see.
>
> As of now I've changed the implementations of Logger within framework (I 
> saw
> some more in the containerkit module, I will change those too).
>
> Now I need to propagate the new level to the childLoggers. And if we stick
> to the Logger approach, this responsibility will belong to Logger. Another
> posibility could be changing the AbstractLogEnabled and LogEnabled to add 
> a
> changeLogLevel method.



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


RE: Avalon-Excalibur Logger

Posted by Jorge CAMPOS <Jo...@gemplus.com>.
I see.

As of now I've changed the implementations of Logger within framework (I saw
some more in the containerkit module, I will change those too).

Now I need to propagate the new level to the childLoggers. And if we stick
to the Logger approach, this responsibility will belong to Logger. Another
posibility could be changing the AbstractLogEnabled and LogEnabled to add a
changeLogLevel method.

What do you think?

Cheers

Jorge

-----Original Message-----
From: hammett [mailto:hammett@uol.com.br]
Sent: Wednesday, January 05, 2005 12:22 AM
To: Excalibur Developers List
Subject: Re: Avalon-Excalibur Logger


Seems very ad-hoc to me. Why?

If you change the ILogger instance you can't assume that the change will
propage to others instances for the same component. If we put that on the
standard API, it will lead people to confusion: "what will be the behavior?
depends on the LoggerManager implementation". The ILogger should be
therefore immutable.


--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett


----- Original Message -----
From: "Jorge CAMPOS" <Jo...@gemplus.com>

> Hi!
>
> I've modified the org.apache.avalon.framework.logger.Logger interface to
> add
> a changeLevel method... I've also changed the implementations to support
> this method... In this way the log level can be reset at runtime.
>
> What do you think about the approach? I've speculated changing
> LoggerManager
> instead, but since you can get a specific logger from the LoggerManager
> the
> right place seemed to be Logger.
>
> If it is OK, is it possible to post it somewhere for consideration towards
> its inclusion in the framework?



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


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


Re: Avalon-Excalibur Logger

Posted by hammett <ha...@uol.com.br>.
Seems very ad-hoc to me. Why?

If you change the ILogger instance you can't assume that the change will 
propage to others instances for the same component. If we put that on the 
standard API, it will lead people to confusion: "what will be the behavior? 
depends on the LoggerManager implementation". The ILogger should be 
therefore immutable.


--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett


----- Original Message ----- 
From: "Jorge CAMPOS" <Jo...@gemplus.com>

> Hi!
>
> I've modified the org.apache.avalon.framework.logger.Logger interface to 
> add
> a changeLevel method... I've also changed the implementations to support
> this method... In this way the log level can be reset at runtime.
>
> What do you think about the approach? I've speculated changing 
> LoggerManager
> instead, but since you can get a specific logger from the LoggerManager 
> the
> right place seemed to be Logger.
>
> If it is OK, is it possible to post it somewhere for consideration towards
> its inclusion in the framework?



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


Re: Avalon-Excalibur Logger

Posted by Leo Simons <ma...@leosimons.com>.
On 04-01-2005 23:51, "Jorge CAMPOS" <Jo...@gemplus.com> wrote:
> Hi!

Hi Jorge!

> I've modified the org.apache.avalon.framework.logger.Logger interface to add
> a changeLevel method... I've also changed the implementations to support
> this method... In this way the log level can be reset at runtime.
> 
> What do you think about the approach?

Hmm. To be honest I think its the wrong way to solve whatever problem it is
you're trying to solve (which I'm kinda guessing about...). The key bit is
that adding a changeLevel() method is saying "look, component, go right
ahead and decide for yourself how much to log", which kind-of violates the
inversion of control principle. The container decides how much of a
component is log messages make it elsewhere, not the component.

> I've speculated changing LoggerManager
> instead, but since you can get a specific logger from the LoggerManager the
> right place seemed to be Logger.

Changing the manager sounds more sensible. I can imagine such a change might
have to be a bit more extensive (I don't know the excalibur-logger code all
that well), but it'll probably be worth it.

> If it is OK, is it possible to post it somewhere for consideration towards
> its inclusion in the framework?

Well regardless of whether such a change is a good idea actually pushing it
into the framework might be problematic. When we change the interface, third
party implementations (for example there's a few that wrap Commons-Logging)
would all need to be modified to support it, and my guess that isn't so
trivial to manage.

(...)

Usually when I have to change some bit of configuration at runtime and that
change isn't transparent to a component instance I tend to just dispose of
the instance and replace it with a new one. Turns out to be a lot easier
than implementing reconfiguration in 80% of the cases. You might want to
consider that :-D

Hope that helps!

Cheers,

Leo



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