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 Jason <lo...@jcg3.org> on 2004/01/19 05:54:47 UTC
configuration additivity and sparse logger trees
Log4j users--
I noticed something odd when I started configuring and testing log4j and
thought I would run it across this mailing list to see what the response is...
I chose to use log4j because of it's fine-grained logging control and the
ability to turn logging on/off for various categories. I tried using the
following configuration for my application:
log4j.logger.ACCESS=ERROR, CONSOLE
log4j.additivity.ACCESS.MyFunction=false
log4j.logger.ACCESS.MyFunction.SubFunction1=INFO, LOGFILE1
log4j.logger.ACCESS.MyFunction.SubFunction2=DEBUG, LOGFILE2
This does not behave as I would expect it to, all the SubFunction1 and
SubFunction2 calls are still going to the CONSOLE in addition to their log
files.
After a little digging through the source code, I realized that there is no
logger created for "ACCESS.MyFunction", so the additivity property set above
never gets used. I can resolve this by putting in an additional config line:
log4j.logger.ACCESS.MyFunction=OFF
Although this is a somewhat reasonable workaround, it is not ideal (I plan on
having _many hundred_ levels where I would have to add these config
directives) . I have to wonder if the code is functioning as designed or if
this is an oversight? There is no comment on this in the online
documentation, and the original configuration should logically work.
Let me know what your thoughts are.
Thanks,
Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re[2]: configuration additivity and sparse logger trees
Posted by Christian Hufgard <ch...@gmx.de>.
Hi,
I do not think of it as a bug. It is thought as a feature, that
log4j-appenders are given to all child-appenders. But I was also
looking for a way to disable this feature per default with a single
line...
Greets,
Christian
J> Thanks for your thoughts... the problem is that I don't want to have to add
J> loggers for each place where I want to turn additivity off. Whether I create
J> loggers by changing the level or adding a null appender doesn't matter-- I
J> still have to set additional config params for a logger just to have the
J> additivity flag processed.
J> I would argue that this is incorrect behavior and might be a bug. Anyone else
J> agree?
J> Would this question be better addressed to the developer's list?
J> Thanks.
>> -----Original Message-----
>> From: Adrian Janssen [mailto:a.janssen@videonetworks.com]
>> Sent: Monday, January 19, 2004 4:21 AM
>> To: 'Log4J Users List'
>> Subject: RE: configuration additivity and sparse logger trees
>>
>>
>> Hi Jason,
>>
>> This is not a solution or explanation, but perhaps you can craft a
>> work-around from the following:
>>
>> I also set the 'additivity' flag to false on a logger that is never
>> explicitly instantiated, however in my case there is an
>> appender attached to
>> the logger, and this seems to work. Perhaps you can change your
>> configuration approach slightly and choose to set
>> 'additivity' flag to false
>> on loggers one level lower in the hierarchy where you are specifying
>> appenders.
>>
>> Cheers
>> Adrian
>>
>> -----Original Message-----
>> From: Jason [mailto:logtastic-mail@jcg3.org]
>> Sent: 19 January 2004 04:55
>> To: log4j-user@logging.apache.org
>> Subject: configuration additivity and sparse logger trees
>>
>>
>>
>> Log4j users--
>>
>> I noticed something odd when I started configuring and
>> testing log4j and
>> thought I would run it across this mailing list to see what
>> the response
>> is...
>>
>> I chose to use log4j because of it's fine-grained logging
>> control and the
>> ability to turn logging on/off for various categories. I
>> tried using the
>> following configuration for my application:
>>
>> log4j.logger.ACCESS=ERROR, CONSOLE
>> log4j.additivity.ACCESS.MyFunction=false
>> log4j.logger.ACCESS.MyFunction.SubFunction1=INFO, LOGFILE1
>> log4j.logger.ACCESS.MyFunction.SubFunction2=DEBUG, LOGFILE2
>>
>>
>> This does not behave as I would expect it to, all the SubFunction1 and
>> SubFunction2 calls are still going to the CONSOLE in addition
>> to their log
>> files.
>>
>> After a little digging through the source code, I realized
>> that there is no
>> logger created for "ACCESS.MyFunction", so the additivity
>> property set above
>> never gets used. I can resolve this by putting in an
>> additional config
>> line:
>>
>> log4j.logger.ACCESS.MyFunction=OFF
>>
>> Although this is a somewhat reasonable workaround, it is not
>> ideal (I plan
>> on
>> having _many hundred_ levels where I would have to add these config
>> directives) . I have to wonder if the code is functioning as
>> designed or if
>> this is an oversight? There is no comment on this in the online
>> documentation, and the original configuration should logically work.
>>
>>
>> Let me know what your thoughts are.
>>
>> Thanks,
>> Jason
>>
J> ---------------------------------------------------------------------
J> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
J> For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: configuration additivity and sparse logger trees
Posted by Jason <lo...@jcg3.org>.
Thanks for your thoughts... the problem is that I don't want to have to add
loggers for each place where I want to turn additivity off. Whether I create
loggers by changing the level or adding a null appender doesn't matter-- I
still have to set additional config params for a logger just to have the
additivity flag processed.
I would argue that this is incorrect behavior and might be a bug. Anyone else
agree?
Would this question be better addressed to the developer's list?
Thanks.
> -----Original Message-----
> From: Adrian Janssen [mailto:a.janssen@videonetworks.com]
> Sent: Monday, January 19, 2004 4:21 AM
> To: 'Log4J Users List'
> Subject: RE: configuration additivity and sparse logger trees
>
>
> Hi Jason,
>
> This is not a solution or explanation, but perhaps you can craft a
> work-around from the following:
>
> I also set the 'additivity' flag to false on a logger that is never
> explicitly instantiated, however in my case there is an
> appender attached to
> the logger, and this seems to work. Perhaps you can change your
> configuration approach slightly and choose to set
> 'additivity' flag to false
> on loggers one level lower in the hierarchy where you are specifying
> appenders.
>
> Cheers
> Adrian
>
> -----Original Message-----
> From: Jason [mailto:logtastic-mail@jcg3.org]
> Sent: 19 January 2004 04:55
> To: log4j-user@logging.apache.org
> Subject: configuration additivity and sparse logger trees
>
>
>
> Log4j users--
>
> I noticed something odd when I started configuring and
> testing log4j and
> thought I would run it across this mailing list to see what
> the response
> is...
>
> I chose to use log4j because of it's fine-grained logging
> control and the
> ability to turn logging on/off for various categories. I
> tried using the
> following configuration for my application:
>
> log4j.logger.ACCESS=ERROR, CONSOLE
> log4j.additivity.ACCESS.MyFunction=false
> log4j.logger.ACCESS.MyFunction.SubFunction1=INFO, LOGFILE1
> log4j.logger.ACCESS.MyFunction.SubFunction2=DEBUG, LOGFILE2
>
>
> This does not behave as I would expect it to, all the SubFunction1 and
> SubFunction2 calls are still going to the CONSOLE in addition
> to their log
> files.
>
> After a little digging through the source code, I realized
> that there is no
> logger created for "ACCESS.MyFunction", so the additivity
> property set above
> never gets used. I can resolve this by putting in an
> additional config
> line:
>
> log4j.logger.ACCESS.MyFunction=OFF
>
> Although this is a somewhat reasonable workaround, it is not
> ideal (I plan
> on
> having _many hundred_ levels where I would have to add these config
> directives) . I have to wonder if the code is functioning as
> designed or if
> this is an oversight? There is no comment on this in the online
> documentation, and the original configuration should logically work.
>
>
> Let me know what your thoughts are.
>
> Thanks,
> Jason
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: configuration additivity and sparse logger trees
Posted by Adrian Janssen <a....@videonetworks.com>.
Hi Jason,
This is not a solution or explanation, but perhaps you can craft a
work-around from the following:
I also set the 'additivity' flag to false on a logger that is never
explicitly instantiated, however in my case there is an appender attached to
the logger, and this seems to work. Perhaps you can change your
configuration approach slightly and choose to set 'additivity' flag to false
on loggers one level lower in the hierarchy where you are specifying
appenders.
Cheers
Adrian
-----Original Message-----
From: Jason [mailto:logtastic-mail@jcg3.org]
Sent: 19 January 2004 04:55
To: log4j-user@logging.apache.org
Subject: configuration additivity and sparse logger trees
Log4j users--
I noticed something odd when I started configuring and testing log4j and
thought I would run it across this mailing list to see what the response
is...
I chose to use log4j because of it's fine-grained logging control and the
ability to turn logging on/off for various categories. I tried using the
following configuration for my application:
log4j.logger.ACCESS=ERROR, CONSOLE
log4j.additivity.ACCESS.MyFunction=false
log4j.logger.ACCESS.MyFunction.SubFunction1=INFO, LOGFILE1
log4j.logger.ACCESS.MyFunction.SubFunction2=DEBUG, LOGFILE2
This does not behave as I would expect it to, all the SubFunction1 and
SubFunction2 calls are still going to the CONSOLE in addition to their log
files.
After a little digging through the source code, I realized that there is no
logger created for "ACCESS.MyFunction", so the additivity property set above
never gets used. I can resolve this by putting in an additional config
line:
log4j.logger.ACCESS.MyFunction=OFF
Although this is a somewhat reasonable workaround, it is not ideal (I plan
on
having _many hundred_ levels where I would have to add these config
directives) . I have to wonder if the code is functioning as designed or if
this is an oversight? There is no comment on this in the online
documentation, and the original configuration should logically work.
Let me know what your thoughts are.
Thanks,
Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org