RE: LogFactory.getLogger()

[Kevin A. Smith]

I'm at work now, but I'll re-compile the patch and post it to the list tonight. Is there any preference to the format of the diff? Normally, I'd just do a diff -R -u between the "official" xindice sources and my locally modified ones. Is this acceptable or should I create diffs on a class-by-class basis?

 

--Kevin

-----Original Message-----
From: Kevin Ross [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 19, 2002 8:48 AM
To: [EMAIL PROTECTED]
Subject: Re: LogFactory.getLogger()

+1 on getClass().getName(), everywhere (not just the server).

I've gotten more experience with commons-logging and log4j, and it will be very easy to turn on and off packages and classes using an xml file for configuration.  Note: (using log4j) a logger will inherit the setting for <this>, <this package>, <parent package>, <grandparent package>, etc, so it will be just as easy to turn the client off.

Here is an example log4j configuration (log4j.xml automatically found as a classpath resource at /log4j.xml):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
    <!--
     
          Log4J Configuration Quick Reference:
          ====================================
      
         
          Priority order is DEBUG < INFO < WARN < ERROR < FATAL
      
      
          PatternLayout conversion characters:
         
           %c   Category of the logging event
           %C   Fully qualified class name of the caller (example: %C{1} would show just the class name instead of the full class name);
           %d   Date of the logging event  (example: %d{HH:mm:ss,SSS} )
           %F   File name where the logging request was issued (caution: extremely slow)
           %l   Location information of the caller (caution: extremely slow)
           %L   Line number from where the logging request was issued (caution: extremely slow)
           %m   Application-supplied message
           %M   Method name from where the logging request was issued (caution: extremely slow)
           %n   Line separator
           %p   Priority of the logging event
           %r   Number of milliseconds since the start of the application
           %t   Name of the thread that generated the logging event
           %x   Nested diagnotic context associated with the thread
           %%   A single percent sign
      
          Format modifiers examples:
         
           %20c     Left pad with spaces if category is less than 20 characters long
           %-20c    Right pad with spaces if category is less than 20 characters long
           %.30c    Truncate from the beginning if category is more than 30 chars long
           %20.30c  Left pad 20 chars + truncate from beginning if more than 30 chars
           %-20.30c Right pad 20 chars + truncate from beginning if more than 30 chars
      
          Examples:  "%r [%t] %-5p %c %x - %m\n"
                     "%-6r [%15.15t] %-5p %30.30c %x - %m\n" 
                     
      -->
    <appender name="console" class="org.apache.log4j.ConsoleAppender">
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="[%d{HH:mm:ss.SSS}-%t][%C{1}][%-5p] - %m\n"/>
        </layout>
    </appender>
    <category name="com.iverticalleap">
        <priority value="debug"/>
    </category>
    <category name="com.iverticalleap.xflow.conf">
        <priority value="info"/>
    </category>
    <root>
        <priority value="info"/>
        <appender-ref ref="console"/>
    </root>
</log4j:configuration>



This will plugin automatically with commons-logging, so no further coding is needed, other than the prescribed use of:

Logger.getLogger(getClass().getName());

-Kevin

Kevin Smith wrote:

I only suggested the package approach because it looked like that was what was 
being done currently. I'm much more in favor of a class.getName() approach 
(that's what I normally do). If this is more appropriate, I'd be happy to 
re-submit the patch with that.

If this isn't a welcome change right now, OK. I'll find something else to fix 
:-)

--Kevin
On Tuesday 19 November 2002 04:25 am, Vladimir R. Bossicard wrote:
  

LogFactory.getLog(SymbolSerializer.class.getPackage().getName());
        

-1 on this one.

CLASS.class.getPackage().getName() only returns the package's name,
without the classname.

One solution would be

    LogFactory.getLog(CLASS.class)

One idea was to have different granularities : one single logger for the
client side and several, finer loggers for the server side.

I'm not a logger pro so I'm open to suggestions. But it's low low on my
todo list :-)

-Vladimir