You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Steve Ebersole <st...@austin.rr.com> on 2001/12/16 18:17:13 UTC
Dynamically overriding Filter/LogLevel for a Category
One of the requirements of the project I am working on is to allow the log
level to be overriden on a user-by-user basis. The idea, for example, is
that all logging levels get set to WARN in our production environment;
however when an issue comes up, I can override the WARN level to DEBUG for
my user only and then login and try to reproduce the problem. I have
already written all the classes to allow this, but wanted to take a look at
Log4J to replace parts of it.
I was thinking I could use Log4J such that "session" would be a top-level
Category, and that all the user-specific messages would log to a Category
("session" + user.getName()). However, I would still need to add the
ability to check a helper class for the current log level for the given
user. Reading the javadocs, I am assuming this would have to be a sub-class
of Filter.
My questions then are:
1) Does this sound like the most reasonable solution to this requirement in
Log4J? I am completely new to the Log4J package, so maybe there's a
better/easier way to accomplish this.
2) If the above approach is OK on the surface, then could I get away with
just writing a Filter class and somehow plug that filter into the standard
Category class, or would I also need to code a new Category sub-class to
recognize the Filter?
Thanks in advance for any advice.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Dynamically overriding Filter/LogLevel for a Category
Posted by Steve Ebersole <st...@austin.rr.com>.
First, thanks for your quick response. Sorry I couldn't get back to you
sooner, but I was without connectivity here the past two days.
Before I started taking a shot at this code-wise, I wanted to run my initial
thoughts by you.
In my existing framework, this whole additional check is called an override.
I think that log4j already has a concept named override, but I'll use that
term here for now. There was two different ways I was thinking of handling
this; both revolve around the priority check in the various Category logging
methods (INTERESTED=DEBUG, INFO, etc):
if (Repository.isDisabled( Level.INTERESTED_INT ))
return;
if (Level.INTERESTED.isGreaterOrEqual( this.getChainedLevel() ))
forcedLog( FQCN, Level.INTERESTED, message, null );
1) Insert an additional "override" check in the failed logic branch of the
current check:
if (Repository.isDisabled( Level.INTERESTED_INT ))
return;
if (Level.INTERESTED.isGreaterOrEqual( this.getChainedLevel() ))
forcedLog( FQCN, Level.INTERESTED, message, null );
else if (overrideEnabled)
if (overrideFilter.continue( this, Level.INTERESTED ))
forcedLog( FQCN, Level.INTERESTED, message, null );
where overrideEnabled and overrideFilter are references based on entries
in the config.
2) Replace the second check with a pluggable "checker":
if (Repository.isDisabled( Level.INTERESTED_INT ))
return;
if (levelFilter.continue( this, Level.INTERESTED ))
forcedLog( FQCN, Level.INTERESTED, message, null );
where the levelFilter reference is an instance of a class specified in
the config. The default filter would simply perform the exact check as it
currently is in the Category/Logger class.
This may be overkill, as I found that there is a way to workaround this
issue in the existing Logger. In the construction of our user-bean, we
could just perform the "outside" override check ourselves, and then call the
Logger.setLevel( NEW_OVERRIDEN_LEVEL );
Also, my framework uses JMS queues instead of Topics. I rewrote JMSAppender
such that it takes an additional config parameter "DestinationType" which
defaults to Topic if none given. Basically, the config looks like:
log4j.appender.JMS1=JMSAppenderProxy
log4j.appender.JMS1.ConnectionFactoryBindingName=weblogic.jms.ConnectionFact
ory
log4j.appender.JMS1.DestinationBindingName=jms/queue/logging
log4j.appender.JMS1.DestinationType=QUEUE
#log4j.appender.JMS1.DestinationBindingName=jms/topic/logging
#log4j.appender.JMS1.DestinationType=TOPIC
If you are interested, I can send you the code; or I could break into two
different classes: one for Topics and one for Queues. If there is any way I
could help out with the project, let me know. I would be happy to help out
with any coding, etc.
----- Original Message -----
From: "Ceki Gulcu" <ce...@qos.ch>
To: "Log4J Users List" <lo...@jakarta.apache.org>
Sent: Sunday, December 16, 2001 4:24 PM
Subject: Re: Dynamically overriding Filter/LogLevel for a Category
>
> At 11:17 16.12.2001 -0600, you wrote:
> >One of the requirements of the project I am working on is to allow the
log
> >level to be overriden on a user-by-user basis. The idea, for example, is
> >that all logging levels get set to WARN in our production environment;
> >however when an issue comes up, I can override the WARN level to DEBUG
for
> >my user only and then login and try to reproduce the problem. I have
> >already written all the classes to allow this, but wanted to take a look
at
> >Log4J to replace parts of it.
> >
> >I was thinking I could use Log4J such that "session" would be a top-level
> >Category, and that all the user-specific messages would log to a Category
> >("session" + user.getName()). However, I would still need to add the
> >ability to check a helper class for the current log level for the given
> >user. Reading the javadocs, I am assuming this would have to be a
sub-class
> >of Filter.
> >
> >My questions then are:
> >1) Does this sound like the most reasonable solution to this requirement
in
> >Log4J? I am completely new to the Log4J package, so maybe there's a
> >better/easier way to accomplish this.
>
> It is a reasonable approach. I am afraid there is no better/easier way.
>
> >2) If the above approach is OK on the surface, then could I get away with
> >just writing a Filter class and somehow plug that filter into the
standard
> >Category class, or would I also need to code a new Category sub-class to
> >recognize the Filter?
>
> Log4j categories do not take filters. Nevertheless, I would be interested
in your solution and would welcome your patch. I also suggest that you
modify the Category class directly, without sub-classing. Regards, Ceki
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Dynamically overriding Filter/LogLevel for a Category
Posted by Ceki Gulcu <ce...@qos.ch>.
At 11:17 16.12.2001 -0600, you wrote:
>One of the requirements of the project I am working on is to allow the log
>level to be overriden on a user-by-user basis. The idea, for example, is
>that all logging levels get set to WARN in our production environment;
>however when an issue comes up, I can override the WARN level to DEBUG for
>my user only and then login and try to reproduce the problem. I have
>already written all the classes to allow this, but wanted to take a look at
>Log4J to replace parts of it.
>
>I was thinking I could use Log4J such that "session" would be a top-level
>Category, and that all the user-specific messages would log to a Category
>("session" + user.getName()). However, I would still need to add the
>ability to check a helper class for the current log level for the given
>user. Reading the javadocs, I am assuming this would have to be a sub-class
>of Filter.
>
>My questions then are:
>1) Does this sound like the most reasonable solution to this requirement in
>Log4J? I am completely new to the Log4J package, so maybe there's a
>better/easier way to accomplish this.
It is a reasonable approach. I am afraid there is no better/easier way.
>2) If the above approach is OK on the surface, then could I get away with
>just writing a Filter class and somehow plug that filter into the standard
>Category class, or would I also need to code a new Category sub-class to
>recognize the Filter?
Log4j categories do not take filters. Nevertheless, I would be interested in your solution and would welcome your patch. I also suggest that you modify the Category class directly, without sub-classing. Regards, Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>