I just added log4j to the external location and it worked. Possibly I think it is the classloader issue. For this thing, I had to wait for 1 week for our release.
Anyway, what I can't understand is how come classes loaded by two different classloaders complain about logging. Possibly I have to delve some more into the code.
thanks for the info Ron. I appreciate it.
vishist.
On 10/7/05, Vishist Mandapaka <[EMAIL PROTECTED]> wrote:
Ron,
Thanks for the info. That really cleared up lot of information. I'm using 1.0.3 JCL. Now, that is the package we received inour corporation. It is part of our entire firewall package. The axis is 1.1 version. As a hint, if the axis is in WEB-INF/lib, no error. But, if the axis is outside the server, then iit is failing. Well I will definetly build on what you said and will try to figure out a solution.
Once again, appreciate your help
vishist.On 10/7/05, Ron Reynolds < [EMAIL PROTECTED]> wrote:that message appears in LogFactoryImpl.getLogConstructor() as the JCL Log factory is trying to figure out how to
create a new Log object
if (!logInterface.isAssignableFrom(logClass)) {
Class interfaces[] = logClass.getInterfaces();
for (int i = 0; i < interfaces.length; i++) {
if ("org.apache.commons.logging.Log".equals(interfaces[i].getName())) {
throw new LogConfigurationException
("Invalid class loader hierarchy. " +
"You have more than one version of '" +
"org.apache.commons.logging.Log" + "' visible, which is " +
"not allowed.");
}
}
throw new LogConfigurationException
("Class " + logClassName + " does not implement '" +
"org.apache.commons.logging.Log" + "'.");
}
i will have to dig deeper into what this code is doing (what might happen if the JCL was loaded by one classloader and
log4j was loaded by another or if 2 copies of log4j got loaded). also what version of the JCL are you using? your
line numbers don't seem to line up with the 1.0.4 source.
also your commons-logging.jar is in /apps/opt/axis? what happens if you move your log4j.jar there as well?
WEB-INF/lib is certainly in a seperate classloader specific to the webapp. if the JCL library is loaded by the
application classloader that would be an easy test-case. tho if the code using the log was also in that higher loader
called by a thread from a lower loader... i dunno - it starts getting rather complicated after a while. let me see
if i can reproduce this error over the weekend (if you can't get it solved before then), ok?
