Log4j-1.3 root logger default to trace?

[Scott Deboy <sd...@comotivsystems.com>]

I'm trying to enable TRACE support in Chainsaw.

The logManager's static block creates a defaultHierarchy with a rootLogger whose level is DEBUG, not ALL or TRACE.

In my attempts to set the level to TRACE, nothing has worked.

My questions:
1. Should the level of logmanager's defaultHierarchy be ALL or TRACE?
   My vote is for ALL.

2. Should both loggerrepository.setThreshold methods be deprecated?  

3. What is the functional equivalent of setThreshold?

4. Is setThreshold what I should be calling in order to programmatically 
   change the root logger's level to TRACE in Chainsaw?
   This didn't work:
   LogManager.getRepositorySelector().getDefaultRepository().
              setThreshold(Level.TRACE);

Thanks

Scott
-----Original Message-----
From:	Jacob Kjome [mailto:hoju@visi.com]
Sent:	Tue 11/30/2004 10:08 PM
To:	Log4J Developers List
Cc:	
Subject:	Re: Log4j-1.3 autoconfiguration default?
At 07:57 PM 11/30/2004 +0100, you wrote:
 >At 06:51 PM 11/30/2004, Jacob Kjome wrote:
 >
 >>I don't have the code to look at right now, so let me see if I'm 
understanding
 >>you.  You are suggesting that we can eat our cake and have it too.  If the
 >>passed in selector doesn't have the default repository set for it, then we
 >>would fall back to the existing default repository (Hierarchy) from the
 >>default
 >>selector.  If this is what you are saying, then yes, I concur.
 >
 >I made small changes to the RepositorySelector interface and to LogManager
 >as discussed in my previous message. It should all work as expected.
 >

Hi Ceki,

Unfortunately, I think you are still missing my point.  The changes to the 
RepositorySelector interface are good.  The change to the LogManager is a 
bit mysterious.  I guess it is trying to protect against overriding the 
default logger repository of custom selectors which initiate a default 
repository in their constructor?  Because that's the only way the default 
repository would actually exist in selectors instantiated within the static 
initialization code of LogManager.  I guess that might be a legitimate 
check?  Can't hurt either way.  However, it doesn't address my original 
point at all, though I can use the same code change from the static 
initialization code within the LogManager.setRepositorySelector() for the 
same effect there, which is what I was trying to point out in the first 
place.  To make it abundantly clear what I am talking about, look at the 
change I just committed.  I'm positive this is correct and it fixes all the 
null pointers which, BTW, cause all apps in Tomcat to cease to work.  It is 
clearly the right thing to do.  If you really disagree, you can always back 
it out, but I can't see why you would want to.

Bottom line is that external initializing code should never ever be able to 
bring down every app in the server by simply forgetting to set a default 
logger repository on the custom selector.  We shouldn't override a default 
logger repository that has been set, but we should definitely make sure it 
doesn't stay null if it wasn't set.  And the default repository of choice 
is the same one that was on the previous selector.  That way, the 
transition is seamless.  Anyway, take a look, and try this under 
Tomcat-5.5.4, not Tomcat-5.0.xx.  Also, the problem would never show itself 
if you started up by passing the selector name in via the -D parameter on 
the command line.  It would only occur in the case where the default 
selector was being used and then some initializer code called 
LogManager.setRepositorySelector().


Jake


 >
 >--
 >Ceki Gülcü
 >
 >  The complete log4j manual:  http://qos.ch/eclm
 >  Professional log4j support: http://qos.ch/log4jSupport
 >
 >
 >
 >---------------------------------------------------------------------
 >To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
 >For additional commands, e-mail: log4j-dev-help@logging.apache.org
 >
 >  


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

Re: Log4j-1.3 root logger default to trace?

[Ceki Gülcü <ce...@qos.ch>]

Scott,

At 08:51 AM 12/1/2004, you wrote:
>I'm trying to enable TRACE support in Chainsaw.
>
>The logManager's static block creates a defaultHierarchy with a rootLogger 
>whose level is DEBUG, not ALL or TRACE.
>
>In my attempts to set the level to TRACE, nothing has worked.
>
>My questions:
>1. Should the level of logmanager's defaultHierarchy be ALL or TRACE?
>    My vote is for ALL.

No, leave it as is.

>2. Should both loggerrepository.setThreshold methods be deprecated?

Yes, they should be deprecated. We'll get to that in due time.

>3. What is the functional equivalent of setThreshold?

Look at the source code for the first lines of any printing method, 
Logger.trace(), Logger.debug(), etc.

>4. Is setThreshold what I should be calling in order to programmatically
>    change the root logger's level to TRACE in Chainsaw?
>    This didn't work:
>    LogManager.getRepositorySelector().getDefaultRepository().
>               setThreshold(Level.TRACE);

No, try:

   LogManager.getRootLogger().setLevel(Level.TRACE)?


>Thanks
>
>Scott

-- 
Ceki Gülcü

  The complete log4j manual:  http://qos.ch/eclm
  Professional log4j support: http://qos.ch/log4jSupport  



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