Bug 5690 - Upgrade log4j version
: Upgrade log4j version
Status: RESOLVED FIXED
: Java WS Core
globus_wsrf_core
: 4.0.5
: Macintosh All
: P3 enhancement
: 4.0.6
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2007-11-27 14:05 by
Modified: 2008-01-07 08:19 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-11-27 14:05:13
We have a user request to upgrade the version of log4j in core, here's the
quote:

as mentioned previously I am having some intermitted problems (basically
sometimes some part of the eXist 1.1.1 wants to call the isTraceEnabled method
and then fails) with the log4j library packaged with the globus WS-Core 4.0.4
(and 4.0.5).

eXist comes packaged with log4j-1.2.14.jar ws-core-4.0.4 comes with
log4j-1.2.8.jar and according to the log4j javadoc Logger.isTraceEnabled
was added in 1.2.12 the most recent version of log4j that I could find was
log4g-1.2.15 (from apache).
------- Comment #1 From 2008-01-03 13:16:06 -------
Aren't higher-level logging frameworks such as Jakarta Commons or SLF4J immune
to this kind of problem?
------- Comment #2 From 2008-01-03 14:35:21 -------
Looked at the JavaDocs for the commons logging library and it looks like before
trace support in log4j, it was treated equivalent to debug. Are you seeing
runtime errors that indicate method is not found or are you referring to the
isTraceEnabled() not returning the correct value?
------- Comment #3 From 2008-01-03 18:50:59 -------
I have updated to the latest version of log4j 1.2.15, independent of this
error. Even with GT 4.0.4 and 4.0.5, you should not see a method not found
error, but TRACE and DEBUG should be treated the same. Let us know if you see a
method not found error.
------- Comment #4 From 2008-01-07 04:01:24 -------
When I get the error, which does unfortunately not always happen, I get a
java.lang.NoSuchMethodError and and from the stack trace it looks like it
directly tries to call org.apache.log4j.Logger.isTraceEnabled() without any
commons library in between, so that is probably why it is not shielded from the
differences. I also did not find any commons logging in the dependencies of
eXist so I guess they are using log4j directly. Anyway below is the stack trace
of some error cases:

java.lang.NoSuchMethodError: org.apache.log4j.Logger.isTraceEnabled()Z
        at
org.exist.xquery.GeneralComparison.quickNodeSetCompare(GeneralCompari
son.java:517)
        at org.exist.xquery.GeneralComparison.eval(GeneralComparison.java:228)
        at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:56)
        at org.exist.xquery.PathExpr.eval(PathExpr.java:216)
        at org.exist.xquery.Predicate.selectByNodeSet(Predicate.java:278)
        at org.exist.xquery.Predicate.evalPredicate(Predicate.java:192)
        at org.exist.xquery.LocationStep.applyPredicate(LocationStep.java:134)
        at org.exist.xquery.LocationStep.eval(LocationStep.java:264)
        at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:56)
        at org.exist.xquery.PathExpr.eval(PathExpr.java:216)
        at org.exist.xquery.ForExpr.eval(ForExpr.java:139)
        at org.exist.xquery.BindingExpression.eval(BindingExpression.java:109)
        at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:56)
        at org.exist.xquery.PathExpr.eval(PathExpr.java:216)
        at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:56)
        at org.exist.xquery.XQuery.execute(XQuery.java:201)
        at org.exist.xquery.XQuery.execute(XQuery.java:171)
        at
org.exist.xmldb.LocalXPathQueryService.execute(LocalXPathQueryService
.java:354)
        at
org.exist.xmldb.LocalXPathQueryService.doQuery(LocalXPathQueryService
.java:300)
        at
org.exist.xmldb.LocalXPathQueryService.query(LocalXPathQueryService.j
ava:122)
        at
org.exist.xmldb.LocalXPathQueryService.query(LocalXPathQueryService.j
ava:113)
        at
se.sgas.xmldb.common.impl.XMLDBCollectionImpl.xquery(XMLDBCollectionI
mpl.java:228)
        at
se.sgas.xmldb.common.impl.LockableXMLDBCollection.xquery(LockableXMLD
BCollection.java:179)
        at
se.sgas.impl.luts.AuditTrailCollection.getAuditTrail(AuditTrailCollec
tion.java:93)
        at
se.sgas.impl.luts.AuditTrailCollectionTest.testGetAuditTrail(AuditTra
ilCollectionTest.java:167)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at junit.framework.TestCase.runTest(TestCase.java:168)
        ...

I hope that cleared up the matter a little bit.

(In reply to comment #3)
> I have updated to the latest version of log4j 1.2.15, independent of this
> error. Even with GT 4.0.4 and 4.0.5, you should not see a method not found
> error, but TRACE and DEBUG should be treated the same. Let us know if you see a
> method not found error.
> 
------- Comment #5 From 2008-01-07 08:19:15 -------
Yes, if log4j was used directly I can see why this happening. With the version
upgrade, you should not see this issue in future GT releases.