RE: Issues with java.util.logging

Hi Scott,
 
Thanks for the response.  See my comments below.  
 
Thanks, 
 
Mike.
 
________________________________

From: [email protected]
[mailto:[email protected]] On Behalf Of Scott Ferguson
Sent: Monday, June 12, 2006 3:20 PM
To: [email protected]
Subject: Re: Issues with java.util.logging




On Jun 7, 2006, at 2:55 PM, Earl, Michael wrote:


	Hi Scott,
	 
	I removed the default <log name="" level="info" .../> and that
didn't help.  Full debug level logging is enabled by default.



There seems to be a missing configuration item for loggers.


Try doing one of the following in that code:


  logger.setLevel(Level.INFO); 
 
Our code will read a file containing logging information like
"com.hp.sfng.<ClassName> = INFO" and peform logger.setLevel call for any
changes.  I have done this to the classes that are logging at the ALL
level and that has mediated the problem with Resin.  Bascially, we can
control the logging level dynamically without having to restart the
server.  This file did not exist on the on the resin server so there
were no preexisting configurations that were causing our logging problem
with Resin.  I added the file and adjusted the logging level for the
classes that were spewing mountains of log messages.  Interestingly
enough, setting a log level to INFO at a name space level like
"com.hp.sfng" did not work; this might be our code but this does work in
other scenarios outside of Resin.


Or


  handler.setLevel(Level.INFO);


The issue looks like a combination of a few things


  1) Handler defaults to Level.ALL 
 
I haven't seen this to be the case before, although it could be.  Even
if the handlers are set to Level.ALL if the logger is not at that level
no logging will occur. 


  2) If Logger.getLevel() is not set, it defaults to the parent. 
 
By default, se set useParentHandlers to false. 


  3) Resin doesn't have a way of configuring Logger.setLevel(...) in the
resin.conf.  The "level" in the resin.conf is always the Handler level,
not the Logger level. 
 
Understand.  But, if you only control the handler log level, how do you
set the Logger log level?  See point on 1) 


  4) If Logger.setLevel isn't set, then for Logger.getLevel, Resin
returns the maximum Handler. 
 
I am not sure what you mean by maxijum Handler.   


Parts 3 & 4 are problems.  In your case, the Handler has Level.ALL,
since that's the default. 
 
Is this default in Java or in Resin? 


#4 is a Resin bug.  I can fix that, although that still doesn't totally
solve your problem.


#3 requires a new configuration item, I think, e.g.


  <logger name="com.hp.sfng" level="info" use-parent-handler="false"/>
 
That sounds like a good solution.  I agree.
 
This would call Logger.setLevel(Level.INFO) on the "com.hp.sfng" Logger.


But there would be a confusion with the current:


<log path="stdout:">
  <logger name="qa" level="info"/>
</log>


The above installs a Handler with handler level="info" in
Logger.getLogger("qa").  It does not actually set the logger's level,
i.e. it really should be handler-level="info". 
 
Understand.  Maybe you can add "loggerLevel" to the config and "level"
still means the handler level.  Or, you could set the logger and
handlers to the value read from the "level" tag.  When we set logging
levels we set the level on the logger and any handlers at the same time.


-- Scott



	 
	Thanks,
	 
	Mike.

________________________________

	From: [email protected]
[mailto:[email protected]] On Behalf Of Scott Ferguson
	Sent: Wednesday, June 07, 2006 7:41 AM
	To: [email protected]
	Subject: Re: Issues with java.util.logging
	
	

	On Jun 6, 2006, at 6:33 PM, Earl, Michael wrote:


		HI Scott,
		 
		We have a LoggerManager class to wrap calls to Logger


		  logger.addHandler( new LogHandler() );
		


	Ah.  You're configuring the logger in your own code.  That's
something I can look into.

	The model Resin uses is that the code gets the Logger and uses
it, but the configuration occurs in the resin.conf file, with the <log>
item.  The "path=..." adds a particular Handler to the Logger.  That
way, configuration is entirely in the conf file.


		Logger logger = LoggerManager.getLogger( this );
		 
		This is essentially what you do below.  
		


	Adding the handler makes a big difference.


		However, we do not use the "shortcut" methods like
logger.fine(), logger.finest() excepting entering() and exiting().  We
always user logger.logp() or logger.entering(), logger,exiting().


	Yes, that's essentially the same thing from the handler code. 

	What may be happening is that the Loggers are all logging at
Level.INFO (because there's a level="info" name="" in the resin.conf.)
If the application's Handler objects are also at Level.INFO, they'd get
displayed, too.

	So, you might need to remove the default <log name=""
level="info" .../> to keep Resin from activating the special handlers.
Or you could just move the log configuration code from the application
into the resin.conf.

	-- Scott


		 
		Thanks for any suggestions,
		 
		Mike.
		 
		
		
		     
________________________________

		From: [email protected]
[mailto:[email protected]] On Behalf Of Scott Ferguson
		Sent: Tuesday, June 06, 2006 4:00 PM
		To: [email protected]
		Subject: Re: Issues with java.util.logging
		
		
		
		
		On Jun 6, 2006, at 2:54 PM, Earl, Michael wrote:


			Hello All, 

			We recently migrated from Tomcat to Resin.  We
are now discovering that for some reason ALL of our classes are creating
log messages at ALL levels.  This did not happen nor does it still
happen with Tomcat -- with the same code.  We love Resin by the way so
this is not a complaint.  I am seeking to understand why this is
happening.  I have added the following to our resin config file:

			<logger name="com.hp.sfng" level="info"
path='stdout:' timestamp='[%H:%M:%S.%s] '/> 

			This had no effect, all classes are sending log
messages.


		Can you give a sample of how you're allocating and using
the Logger?  Our standard pattern is:

		package com.caucho.foo;

		public class Bar {
		  private static final Logger log =
Logger.getLogger(Bar.class.getName());

		Then we use
		  log.info - stuff users should see
		  log.finer - stuff application writers will want to see
to help debugging
		  log.finest - more details for us to debug, but which
may be cryptic to outside developers

		-- Scott
		


			Thanks for any help, 

			Mike. 

	
--------------------------------------------------- 
			Michael Earl           "For whoever exalts 
			Software Engineer       himself will be humbled,

			GO-IT MBP/SF            and whoever humbles 
			Bldg R4                 himself will be
exalted." 
			HP, Roseville CA                         
			+1-916-748-7958 work    Matthew 23:12 
			+1-916-671-4466 cell    
	
---------------------------------------------------