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.
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 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. 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. 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 -- 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] _______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
