Hi there, I'd like to share a cautionary take about using an ObjectRenderer which I hope people might find useful. I'm using log4j-1.2.9 not only for my developer-level logging but also for a localized, end-user log, much in the same way as discussed in the "Backend l10n" thread on this list. I log objects, not strings, have a custom Appender that checks for a LoggingMessage containing an instance of that class and routes it to the end-user log, deferring translation to the viewer application. It works very well and I can still use log4j for my debug strings, which the custom Appender ignores.
Including these end-user log messages in my development log seemed like an ideal opportunity to use an ObjectRenderer, which could call on a suitable translator object to look up the resources in a language I can read. However I was at first surprised at a problem that occurred once I set my logging back to the debug level. The items that used the renderer appeared not to be applying the PatternLayout correctly. It turns out that the Appender (through the PatternLayout that was calling the renderer) was being called re-entrant. The translator object that my renderer was using was itself making log4j calls, which log4j components (like appenders or renderers) cannot do. It seems I would have to make sure any component I called in a renderer (or even in my toString() method) didn't log anything. How can I avoid this? So far, the only idea I have had has been to put my renderer in a diagnostic context that I can later filter against to suppress the re-entrant logging calls, but that's surely not the right way to do it. For now I can get by with a much simpler toString() method, but I wondered if there was a more general solution. Many thanks for your consideration Chris Nash Lexmark International, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
