https://issues.apache.org/bugzilla/show_bug.cgi?id=43867
--- Comment #39 from Dan Armbrust <[EMAIL PROTECTED]> 2008-07-09 13:30:27 PST
---
Ok. First - how to make this easier for others to find:
Before closing this bug, I suggest a change along the following lines.
In LogManager, line 177, the following line:
LogLog.error("LogMananger.repositorySelector was null likely due to error in
class reloading, using NOPLoggerRepository.");
Could be changed to something like this:
LogLog.error("LogMananger.repositorySelector was null likely due to error in
class reloading, using NOPLoggerRepository.", new Exception("Stack of offending
thread").fillInStackTrace());
Which would be vastly more helpful if you insist on leaving this message in
place. However, read-on....
On to the real issue - and this is interesting - even more of our assumptions
are wrong. This has nothing to do with finalizer code. And in fact, has
nothing to do with any code that I had deployed in my webapp. The problem
happens purely within the Main thread, being executed by tomcat.
It happens because of a basic design issue between tomcat and log4j - and if
you ask me the error is purely in tomcat.
So, previously, I had traced the main thread all the way down to
reflectionFactory.newFieldAccessor(this, overrideFinalCheck);
as Tomcat was setting things to null - then I couldn't follow any farther, due
to a lack of source code.
Working backwards from log4j, here is the offending stack:
LogManager.getLoggerRepository() line: 177
LogManager.getLogger(String) line: 199
Logger.getLogger(String) line: 105
Log4JLogger.getLogger() line: 229
Log4JLogger.<init>(String) line: 65
GeneratedConstructorAccessor5.newInstance(Object[]) line: not available
DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27
Constructor<T>.newInstance(Object...) line: 513
LogFactoryImpl.newInstance(String) line: 529
LogFactoryImpl.getInstance(String) line: 235
LogFactoryImpl.getInstance(Class) line: 209
LogFactory.getLog(Class) line: 351
ValidatorForm.<clinit>() line: 99
Unsafe.ensureClassInitialized(Class) line: not available [native method]
UnsafeFieldAccessorFactory.newFieldAccessor(Field, boolean) line: 25
ReflectionFactory.newFieldAccessor(Field, boolean) line: 122
The only code here that isn't from log4j or sun is:
ValidatorForm.<clinit>() line: 99
That particular class is org.apache.struts.validator.ValidatorForm from struts.
What is happening on line 99 is:
private static Log log = LogFactory.getLog(ValidatorForm.class);
Which is certainly not unusual - I don't think struts has anything to do with
causing the problem. It's more of just luck - depending on the order that
tomcat runs through the classes as it clears references.
Tomcat, in the desire to clear out the static fields within a class by using
reflection, has unwittingly caused the class init code to be rerun due to the
way that reflection works. When it hits this code that tries to use the log
factory, it doesn't know that it has already broken the logfactory by setting
fields within the logfactory to null.
So, the logfactory prints the error.
Short of making tomcat stop clearing references - I don't think there is any
way for me as a web developer to prevent this error.
Therefore, with that argument, I think that we need a way to make log4j not log
this as an error. I think this particular message needs to go back to being a
info or a debug level message.
And I'm going to re-raise this issue on the tomcat bug tracker, but I doubt
that they will make any changes, since there is really no way for them to know
what a safe order is for clearing references - and they still insist on
clearing references by default.
--
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]
