I'm using 1.2.11, but in my Internet searching, I've seen someone else
getting the exact same error in 1.2.13 (google: NullPointerException
org.apache.log4j.NDC.get). I will upgrade my app.

Why would Thread.getCurrentThread() return null? Shouldn't that always
return a non-null value?

Thanks for the response and suggestions! I'm hoping that it will
happenly rarely enough to be overlooked until someone else identifies
the issue and develops a good patch. Or until 1.3 is officially
released.

On 7/10/06, Curt Arnold <[EMAIL PROTECTED]> wrote:

On Jul 10, 2006, at 9:30 AM, Giesen Giesen wrote:

> I sporadically get the following error when my JSF app starts up.
> Anyone know what I can do? Would the 1.3 alpha version help? (I hate
> to use prerelease software)
>
> Exception sending context initialized event to listener instance of
> class com.sun.faces.config.ConfigureListener
> java.lang.NullPointerException
>       at org.apache.log4j.NDC.get(NDC.java:209)
>       at org.apache.log4j.spi.LoggingEvent.getNDC(LoggingEvent.java:238)
>       at org.apache.log4j.helpers.PatternParser
> $BasicPatternConverter.convert(PatternParser.java:401)
>       at org.apache.log4j.helpers.PatternConverter.format
> (PatternConverter.java:64)
>       at org.apache.log4j.PatternLayout.format(PatternLayout.java:503)
>       at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:301)
>

You didn't mention what version of log4j 1.2.x you were using, so it
isn't easy to match line numbers with particular statements.  In the
latest log4j 1.2.x source, NDC.java:209 is:

     Stack s = (Stack) ht.get(Thread.currentThread());

The two mechanisms that I would see for a NullPointerException would
be if either ht or Thread.getCurrentThread() are null.  I do not see
a mechanism for either of those to happen.  Unfortunately, "ht" is
neither private or final so there is a possibility that some other
class modifies the value.  That appears to be unanticipated as ht ==
null is never checked in any of the other accesses of the variable.

I assume that in your layout, you have a layout specification like: %X
{FOOBAR} that could be removed to eliminate going down evaluating the
NDC which might allow you to avoid the bug.

log4j 1.3.x appears to use a substantially different implementation.
So it might not have this issue, but I would not recommend changing
based on this issue until it is understood.

Please let us know what version of log4j you are running.  If not the
current log4j 1.2.x, does the problem appear with latest log4j
1.2.x?  If it does, if you could figure out whether
Thread.currentThread() is returning null or ht is null.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to