RE: Issues with java.util.logging

"Earl, Michael" <[email protected]> Wed, 7 Jun 2006 08:32:04 -0700
Newsgroups gmane.text.xml.resin.user
Message-ID <96ECC502D2678A4192F48386A524718D04E2B75A@cacexc07.americas.cpqcorp.net>
Hi Scott,
 
Thanks for the reply see my comments below (in red):
 
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. 
 
Yes, we do this:
 
Here's all of the code where we get the logger from the java Logger
factory and then add our own handlers.  We send out our log messages via
multicast.  If multicast is not working we use RMI.  The LogHandler
handler handles this logic.  So in this method below we get the Logger
instance for the class "com.hp.sfng....." and add a LogHandler to the
handlers of the logger.
 
    static public Logger getLogger( String loggerName )
    {
        String METHOD = "getLogger";
        Logger logger = Logger.getLogger( loggerName );
        // Don't add the handlers if logging is disabled.
        if( isLoggingEnabled() )
        {
            // Add handlers to the logger            
            if ( logger.getHandlers() == null ||
logger.getHandlers().length == 0 )
            {
                try
                {
                    if ( (loggingMode & MULTICAST_LOGGING) ==
MULTICAST_LOGGING )
                    {
                        logger.addHandler( new LogHandler() );
                    }
                    
                    if ( (loggingMode & STDERR_LOGGING) ==
STDERR_LOGGING )
                    {
                        logger.addHandler( new StderrHandler() );
                    }
                }
                catch ( Exception e )
                {
                    System.err.println( "Error adding LogHandler() to
the logger: " + e.getMessage() );
                }
            }
            // WE do dot want to propogate any messages or the system
logger will output to the console
            logger.setUseParentHandlers( false );
        }
        return logger;
    }
 


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. 
You are probably right, I am not sure why adding a handler is causing
our problem though.  In our Java application, which uses the same code
as our web code, we do not have this logging issue.



	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.
 
Well, the problem is all of the FINE, FINER, and FINEST logs are also
being sent out (multicast) not just the INFO.  We want to see the INFO
messages.
 
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. 
 
I had the same thought about removing that line.  I will try it and get
back to you on that.   We can't remove the log configuration code from
our Application just to fix the Resin issue, as mentioned above, our
code is used in our Java application and our Servlets for the web.  The
servlets under resin are having the issue not the Java Application.
 
Thanks a lot Scott.


-- 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    
		---------------------------------------------------