DO NOT REPLY [Bug 41939] NPE in Logging due to classloading

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Comment #24 from Mark Thomas <[EMAIL PROTECTED]>  2008-07-09 14:01:42 PST 
---
Yes, if you and the libraries you use code their use of loggers correctly you
should be safe with setting ENABLE_CLEAR_REFERENCES to false.

I can't speak for the other developers but I am happy with the current default
for this being true on the basis it fixes more issues than it causes.

That said, I am more than happy to look into any test case (like bug 42172)
that could be a Tomcat memory leak.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

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

DO NOT REPLY [Bug 41939] NPE in Logging due to classloading

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Comment #23 from Dan Armbrust <[EMAIL PROTECTED]>  2008-07-09 13:40:47 PST 
---
Could someone with knowledge of this bug read through this comment on a bug in
Log4j?

https://issues.apache.org/bugzilla/show_bug.cgi?id=43867#c39

I believe that this is an example of tomcat breaking other code due to the way
that it clears references, when
org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES is left to
its default of "on".

In this case, log4j prevents a null pointer, and simply logs an error.  But
other code could very easily take a null pointer for the same reason.

It doesn't seem like the current implementation of clear references is safe to
use.

Comment #17 indicates that clearReferences is a workaround to a different bug,
and won't be removed.  Perhaps that should be re-evaluated.  

I now have to disable clearReferences on my tomcat installs on most of my
webapps which use log4j to prevent users from seeing a scary looking error
being logged by log4j.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2007-11-02 13:27 ---
I'm wary of the implications of the comments in this bug. Let me summarize to
make sure we're all on the same level. I'm coming from bug 40212, btw.

- To get per-app logging, one has to use the setup of comment #16 (one instance
of log4j and commons-logging per tomcat and per webapp).

- If you do this, you can get NPEs at the next startup because Tomcat clears
static fields during undeploy.

Can you explain to me how it can be possible that the instance N+1 of my webapp
can see anything from instance N? If that would happen, it would either mean 

a) that tomcat is handing me classes which are in the common classpath despite
them being overridden in my webapp
b) that I get references to classes which ought no to exist anymore

a) means that classes from tomcat leak into my webapp and b) means that classes
from instance N can leak into N+1. Neither must be possible.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Additional Comments From [EMAIL PROTECTED]  2007-04-23 19:43 ---
Having looked at this in more detail there is still a theoretical possibility of
an NPE unless the system
property
org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES is set to 
false

Any such occurrence should be rare.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Additional Comments From [EMAIL PROTECTED]  2007-04-22 17:34 ---
Note that after some further investigation the root cause is actually a logging
related memory leak (bug 42172). This leak has been fixed in svn and the test
case for this issue now runs without an NPE with or without setting the system
property
org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES to false.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-04-19 20:20 ---
I have added this configuration option to svn. The provided test case no longer
throws an NPE on reload, providing the new configuration option is set to false.

This will be included in 5.5.24 onwards.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2007-04-19 20:00 ---
*** Bug 37956 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |




--- Additional Comments From [EMAIL PROTECTED]  2007-04-19 19:59 ---
I am re-opening this since the bug is the result of the nulling out static and
final fields from classes loaded by the web app classloader. As noted in the
code comments this is a workaround for some apparent GC bugs.

The workaround will not be removed since it is useful for many users and has
been shown to resolve some memory leak issues.

I will make this workaround optional in TC5.5.x, as it is in TC6.0.x.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Additional Comments From [EMAIL PROTECTED]  2007-04-19 16:49 ---
I am hunting for permgen leaks as the moment and have wildly inconsistent
results with context reloading. Most of the time the first loaded webapp will
not garbage but some subsequent reloads are grabaged.

The Tomcat FAQ section should have it spelled out under a title called 'Log4J'
the best way to include log4j and the implications of having the
commons-logging. Currently the 'How should I log in my own webapps?' section
'strongly recommends' using log4j but does not address any of these issues.
There are many different approaches listed on the web some of which go as far as
replacing the bootstrap logging.

e.g.

/commons/lib/commons-logging.jar
/commons/lib/log4j.jar
/commons/classes/log4j.properties

//WEB-INF/lib/log4j.jar
//WEB-INF/lib/commons-logging.jar
//WEB-INF/classes/log4j.properties

It should spell out things like the following:

If you have commons-logging.jar in your webapp then it will not garbage.

If you don't have log4j.jar in your webapp then you will not get per-content
logging of you //classes/log4j.properties file

Kind regards
James McIntosh

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Additional Comments From [EMAIL PROTECTED]  2007-04-19 09:14 ---
org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES only has an
effect in the 6.0.x branch. This option hasn't been ported to the 5.5.x branch.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2007-04-19 08:29 ---
(In reply to comment #13)
> Ok, you did not post the NPE, so I cannot know for sure. Regardless, this 
> issue
> is not going to be addressed, and you should probably be packaging your web
> application differently.

There is little variation between my NPE and the one that has been posted
previously.

By "packaging your web application differently", what exactly do you mean?
Placing log4j in the container classpath instead of the application classpath?
Not using a separately packaged commons-logging? Not using log4j at all?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Additional Comments From [EMAIL PROTECTED]  2007-04-19 08:05 ---
Ok, you did not post the NPE, so I cannot know for sure. Regardless, this issue
is not going to be addressed, and you should probably be packaging your web
application differently.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 OS/Version|Windows XP  |All
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2007-04-19 08:00 ---
(In reply to comment #10)
> Set the system property
> org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES to false.

I set this property in $JAVA_OPTS to false. I additionally verified that the
property was, in fact, being set by querying System.getProperty().

However, setting this property to false has no effect with regards to resolving
this bug.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Additional Comments From [EMAIL PROTECTED]  2007-04-19 07:11 ---
I attached two test cases. The first contains a vanilla binary of log4j 1.2.14,
and it does exhibit the NPE behavior. The second contains a modified binary of
log4j 1.2.14, and it does NOT exhibit the NPE behavior. More details regarding
the  test cases can be found by clicking on the attachment links.

Two further notes, though:

1.) The NPE behavior is exhibited in the first test case regardless of whether
the servlet containing the log reference has been previously invoked.

2.) The first test case does NOT exhibit the NPE behavior under tomcat 6.0.10. I
suspect that this has something to do with the standardization of logging under
that tomcat platform.(In reply to comment #10)

> Set the system property
> org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES to false.

Why?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-04-19 07:03 ---
Set the system property
org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES to false.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Additional Comments From [EMAIL PROTECTED]  2007-04-19 06:59 ---
Created an attachment (id=20002)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20002&action=view)
This WAR Contains a Modified Log4j That Does NOT Exhibit NPE Behavior

This WAR is identical to "20001: Simple War File That Demonstrates NPE Behavior
on Reload" except that it contains a version of log4j that I modified.

Recall that I stated that there are several static members in log4j classes
that are being improperly nullified and not re-initialized. The modifications
that I made to the log4j binary included in this WAR simply amount to checking
if the members in question are in a null state before using them. Then, if they
are null, I re-initialize the members to their starting values.

This WAR does NOT exhibit a NullPointerException when reloaded. Additionally,
the servlet continues to function normally after several reloads.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Additional Comments From [EMAIL PROTECTED]  2007-04-19 06:53 ---
Created an attachment (id=20001)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20001&action=view)
Simple War File That Demonstrates NPE Behavior on Reload

I deployed this WAR on the 5.5.20 and 5.5.23 binary distributions.

This WAR contains a simple servlet that contains a static reference to a Log
instance. The vanilla binary of log4j 1.2.14 is on the classpath, so
commons-logging is using the log4j log provider.

The servlet runs as expected (it just prints a message to the client and prints
the same message in the log). However, when I click on the reload link for the
application in the manager web application, the context fails to reload with a
NullPointerException.

The NullPointerException traces back to log4j classes. Specifically, I
discovered that there are several instances where static members of the log4j
classes in question are improperly set to null by something outside of log4j
and not re-initialized.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Additional Comments From [EMAIL PROTECTED]  2007-04-09 16:36 ---
The issue is that something is keeping a reference to a logger that it
shouldn't. This is going to cause a memory leak and what you are seeing are the
side-effects of Tomcat's attempts to prevent memory leaks.

If you can provide the simplest possible test war the exhibits this issue I'll
happily debug my way though the code and figure out what is going wrong. Without
such a test case, there is little that can be done to investigate this issue.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Additional Comments From [EMAIL PROTECTED]  2007-03-27 02:34 ---
I have no additional threads running in this application. Besides that, in all
applications we manage, the running threads are stopped on destroy(). 

But neverthelesse: I have started to move JARs around and have now the following
situation: 

Like Robert Weber, I have no Log4J and no commons-logging in the commons/lib or
in shared/lib. 

I have a logging.properties in commons/classes.

I have commons-loggings and log4j only ONCE in the webapplication this is tested
with. 

UNloading works fine, as soon as reloading starts, the NPE is thrown. This time
it is not even inside the application, but in Tomcat Manager. I guess, that the
class in log4j is already distorted. 

Could it be that tomcat or commons-logging thinks it should use log4j because
the classes are found inside the application?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Additional Comments From [EMAIL PROTECTED]  2007-03-27 02:31 ---
Why should static members be reset to null? When static members are reset to
null, do they eventually get re-initialized? For instance if I declare:

static String foo = "bar";

When the context re-load completes, does "bar".equals(foo) evaluate to true?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 17:12 ---
You do remember that when you undeploy an application (while restarting it), the
tomcat classloader reflects on all the classes it's unloading, and resets any
static members to null.

Depending on the order in which it does this, if there are some other threads
still running, they can get NPEs..

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939





--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 06:38 ---
This bug should not be dismissed. My own web application includes one instance
each of commons-logging-1.1.jar and log4j-1.2.14.jar. My
$CATALINA_HOME/common/lib does not contain a commons-logging jar (unless the
class files are embedded in one of the other jars???).

Additionally, the NPE is thrown by log4j code. In fact, I have done some
debugging on the log4j code-base, and the behavior that I witnessed defied
standard java convention. That is, the NPE is caused by certain static class
fields (whose values are set at instantiation) arbitrarily becoming null when
one attempts to reload the context that contains the log4j jar. In effect,
certain static members of the log4j classes are not being re-initialized when
the context is reloaded.

For my part, I have worked around the issue by patching my log4j to
re-initialize the problem fields itself when they are detected to be null, but
in all honesty, this hack should be unnecessary.

Now, I would not say that this bug is a number one priority show-stopper (or
even that it should be fixed), but it should, at least, be acknowledged.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2007-03-26 03:42 ---
Then: Why does the very same package deploy on 5.5.9?

And: Yes there are duplicate classes in the packages, but in the end you will
never be able to avoid it. 

And: There is the, mabe even written law, that it is definitely good practice
that one should package all required classes inside the web-app\lib path,
besides native lib adapters. If this is suddenly not true any more, then how do
you deploy different independent applications with incompatible commons-logging
implementations? 

The answer may be easy for you, but I think that I have done valid packaging and
that the classloader is in fact mixing packages from /common/lib with packages
from my application web-inf/lib on application reload.

It looks like it is preferring the common/lib instance of the jar on reloading,
not recognizing, that there is a jar in WEB-IN/lib carrying the same class.
Following the rules of classloading, the Web-App's jar should be used. 

But you are free to correct me if I am wrong.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41939] - NPE in Logging due to classloading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-03-25 13:51 ---
I doublt we should adjust very well-tested classloader because your packaging is
messed up.  It's your responsibility (or the responsibility of whoever packages
your webapp) to not include duplicate and/or conflicting versions of its
dependent libraries.

If you can't do this, at the very least you will want to separate Tomcat's
logging libs from your own, perhaps by moving the commons-logging stuff from
$CATALINA_HOME/common/lib to $CATALINA_HOME/server/lib.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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