You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Chris Nash <ch...@prodigy.net> on 2005/02/24 20:41:12 UTC
Object renderers, re-entrant appenders
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: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Object renderers, re-entrant appenders
Posted by Ceki Gülcü <ce...@qos.ch>.
It's a bug I am current working on. The recent changes in the Appender
interface relate to this problem.
At 09:20 PM 2/24/2005, James Stauffer wrote:
>I encountered a similar problem and my code was endlessly recursive.
>In my instance:
>Database pool code logged to log4j
>logj sent errors to a customer Database Appender
>The Database Apppender used the same Database pool code.
>So if there was a connection problem it would be endlessly recursive.
>Now l have log4j configured to never log anything in the Database code
>to the Database.
>--
>James Stauffer
>http://www.geocities.com/stauffer_james/
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Object renderers, re-entrant appenders
Posted by James Stauffer <st...@gmail.com>.
I encountered a similar problem and my code was endlessly recursive.
In my instance:
Database pool code logged to log4j
logj sent errors to a customer Database Appender
The Database Apppender used the same Database pool code.
So if there was a connection problem it would be endlessly recursive.
Now l have log4j configured to never log anything in the Database code
to the Database.
--
James Stauffer
http://www.geocities.com/stauffer_james/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Object renderers, re-entrant appenders
Posted by Curt Arnold <ca...@houston.rr.com>.
On Feb 24, 2005, at 1:41 PM, Chris Nash wrote:
...
> 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
>
Were you seeing a deadlock on the logging within the renderers or some
other issue? I have on my (lengthy) TO-DO list a fairly thorough
analysis of LoggingEvent and rendering was one area that I thought was
troubling.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Object renderers, re-entrant appenders
Posted by Chris Nash <ch...@prodigy.net>.
Thank you for the very prompt and informative replies. They have been
very helpful indeed and pointed me towards a few other things to try.
--- Ceki G�lc� wrote:
> Is this log4j 1.2 or 1.3?
I was using log4j 1.2.9. I followed your suggestion and went ahead to
try 1.3-alpha6, and tried a similar situation with a FileAppender. That
seemed to resolve the problem. Thank you!
--- Curt Arnold wrote:
> Were you seeing a deadlock on the logging within the renderers or some
> other issue?
What I was getting under 1.2.9 was output not formatted correctly by the
PatternLayout. The log call inside the renderer appeared as expected,
but the log call that invoked the renderer lost its formatting:
2005-02-24 15:39:31,229 DEBUG - a string logged by the renderer itself
The message that used the renderer (no %d %p items here)
That no longer happens under 1.3. In addition, log4j-1.2.9 caught an
IOException for "stream closed" on a couple of rare occassions while
inside the RollingFileAppender, when the 'inner' call caused a rollover.
I have to get my configuration moved over to XML before I can test for
that issue under 1.3.
--- James Stauffer wrote:
> I encountered a similar problem and my code was endlessly recursive.
Although 1.3 appears to fix the formatting issue, it still sounds like
I'm getting away with something I really shouldn't be doing -
helpers.LogLog makes it quite clear it's something not to do. Now I know
what re-entrancy can do, I should be able to recognize and avoid it next
time.
Thank you all for all your help.
Chris Nash
Lexmark International, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Object renderers, re-entrant appenders
Posted by Ceki Gülcü <ce...@qos.ch>.
Is this log4j 1.2 or 1.3?
At 08:41 PM 2/24/2005, Chris Nash wrote:
>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: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org