logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Smith <psm...@aconex.com>
Subject Re: Depracating LogLog
Date Fri, 19 Nov 2004 00:05:48 GMT
Actually, silly me, it''s just easier to follow the "static" example you 
provided in this case.  Still, should we use a instance level logger in 
favour of the static factory method  approach if possible?

Paul

Paul Smith wrote:

> Hi Ceki,
>
> I am just starting this work, and thought I should clarify something.  
> I'm starting in the config package (PropertyGetter), which is 
> different from the Appender example you mention below.  Do you think  
> I am safe to add:
>
> private final Logger LOG = Logger.getLogger(PropertyGetter.class);
>
> (note the lack of static here, following your lead mentioned below).  
> And then use this Logger in place of LogLog?
>
> cheers,
>
> Paul
> Ceki Gülcü wrote:
>
>>
>> Howdy,
>>
>> In the process of moving away from LogLog, we need to replace LogLog
>> statements with their Logger equivalents. For example,
>>
>>   LogLog.debug("hello");
>>
>> becomes
>>
>>   getLogger().debug("hello");
>>
>> where getLogger() is a method of the class being modified.
>>
>> For all appenders deriving from AppenderSkeleton this method exists
>> already.
>>
>> public class AppenderSkeleton implements Appender, OptionHandler {
>>
>>   /*
>>    * An inststance specific logger.
>>    */
>>   private Logger logger;
>>
>>   /**
>>    * Return an instance specifi logger to be used by the Appender 
>> itself.
>>    * This logger is not intended to be used by Mrs. Piggy, our 
>> proverbial user,
>>    * hence the protected keyword.
>>    *
>>    * @return instance specific logger
>>    */
>>   protected Logger getLogger() {
>>     if(logger == null) {
>>       logger = LogManager.getLogger(this.getClass().getName());
>>     }
>>     return logger;
>>   }
>>
>>     .... rest of AppenderSkeleton code
>> }
>>
>> In case application share the same log4j classes in memory and logging
>> separation achieved by a RepositorySelector, say ContextJNDISelector,
>> then we must be careful to use a different Logger instance depending
>> on the application, hence the per instance Logger in
>> AppenderSkeleton. Since will be only few Appender instances, there
>> should not be a performance significant hit.
>>
>>
>> For classes with only static methods, there is a similar pattern:
>>
>> public class SomeClassWithOnlyStaticMethods {
>>
>>   public static foo() {
>>     getLogger().debug("hello...");
>>   }
>>
>>   /**
>>    * Gets a logger named after this class. Note that the instance of the
>>    * logger may change depending on the
>>    * {@link org.apache.log4j.spi.RepositorySelector}.
>>    * @return a context dependent Logger
>>    */
>>   private static Logger getLogger() {
>>     return LogManager.getLogger(OptionConverter.class);
>>   }
>> }
>>
>> In general, log4j classes should use logging for warning or error
>> messages.
>
>
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message