For info.
--
Ceki Gülcü
QOS.ch is looking to hire talented developers located in Switzerland
to work on cutting-edge software projects. If you think you are
qualified, then please contact [EMAIL PROTECTED]
--- Begin Message ---
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
--- End Message ---
_______________________________________________
dev mailing list
[email protected]
http://www.slf4j.org/mailman/listinfo/dev
