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

[Ralph Goers]

Thanks.  See comments below.

Ceki Gulcu wrote:
> Hello Ralph,
>
> I just committed a modified version of your logging utility class in
> revision 1091 and 1092. The code is based LoggerUtil that you kindly
> attached to bug 86. As you can see there are several differences
> between LoggerUtil and what was committed.
Thanks for doing that.
>
> 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.
>
> 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).
>
> I also made use of containment relationships in markers. For example,
> entry() calls are marked with the ENTRY marker which contains FLOW
> marker as a child. Similarly, exit() calls are marked with EXIT which
> contains FLOW as a child. This makes it easy to enable/disable both
> entry and exit calls by acting on the FLOW marker.  Alternatively, one
> could enable/disable only exit() class by acting on the EXIT marker.
That should be fine.
>
> In the future, we could envisage adding i18n functionality to
> XLogger. Working with instance objects gives an indirection point
> where we can inject bundles during initialization by say an
> XLoggerFactory. See also [1].
>
> It's still work in progress. So WDYT?
>
> [1] 
> http://www.nabble.com/Internationalisation-of-log-messages-to14360301.html 
>
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.

Ralph