[slf4j-dev] SLF4J extensions, LoggerUtil, bug 86

[Ceki Gulcu]

Ralph Goers wrote:
> Ceki Gulcu wrote:

[snip]

>> First, the class is called XLogger and it wraps an SLF4J logger
>> provided during construction time. It follows that XLogger methods are
>> no longer static.
 >
> The downside to this is that it might result in a lot of unnecessary 
> object construction depending on how the application is coded. 
> Presumably, getLogger() will always return the same Logger instance, at 
> least until a reconfigure occurs. But applications may tend to create 
> XLogger more frequently - which doesn't buy much since XLogger doesn't 
> contain any attributes - at least not yet.

Not that it matters in this context, the Logger instance returned by 
LoggerFactory.getLogger will remain the same, even after reconfiguration. But 
you are right, multiple xlogger instances might be created for (or 
encapsulating) the same logger instance.

At this early stage, the only immediate advantage of instance xlogger is brevity.

For example, with instance methods we write:

class A {

   static Logger logger = LoggerFactory.getLoggerFactory(A.class);
   static Xlogger xlogger = new XLogger(logger);

   void foo() {
     xlogger.entry();
     ...
     xlogger.exit();
   }

   void foo(int i) {
     xlogger.entry(i);
     ...
     xlogger.exit();
   }

}

instead of the previous:

class A {

   static Logger logger = LoggerFactory.getLoggerFactory(A.class);

   void foo() {
     XLogger.entry(logger);  <-- keep passing the logger instance
     ...
     XLogger.exit(logger); <-- again
   }

   void foo(int i) {
     XLogger .entry(logger, i); <-- and again
     ...
     XLogger .exit(logger);  <-- and again
   }
}

I think that the former (instance methods) are a  little easier on the fingers 
and on the eyes.

>> The enter method was renamed as entry to be consistent with exit. More
>> importantly, it has only one variant taking a vararg (Object...). This
>> is not as optimal as having multiple signatures for the primitive
>> types and the like. The difference is in the order of 200 nano-seconds
>> which should not matter unless the xlogger statements are invoked
>> millions of times. I am assuming that most xlogger statements are
>> intended for development and will be *manually* removed in production
>> code. The few remaining xlogger calls, if any, should not have an
>> impact.
> We leave ours in. If they have expensive parameter construction they can 
> be wrapped with isEnabled type calls. Ideally, flow tracing should be 
> injected via AOP. Having the scaffolding there should help. Once I 
> create something to do that I will post it back here (unless someone 
> beats me to it).

Thorbjørn Ravn Andersen has done some work on precisely on the topic of logging 
AOP [1]. Maybe he  could be persuaded to contribute his work here.

> The only other concern I have is the lack of unit tests. In what I sent 
> you I had created a Logger suitable for use in unit testing. That, or 
> something similar, should be incorporated into a test package so that 
> more thorough unit tests can be developed.

unit tests? Is that about calibrating units of measure such as distance or time? 
:-)

Kidding aside, I did not want to commit to unit tests without your input. If you 
are OK with the general design, I'll be happy to add unit tests as appropriate.

> Ralph

[1] 
http://today.java.net/pub/a/today/2008/04/24/add-logging-at-class-load-time-with-instrumentation.html
[1] the same but shorter: http://tinyurl.com/5brqh4


-- 
Ceki Gülcü