You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by s r <rk...@lycos.com> on 2006/03/28 23:16:29 UTC
Strange problem with Digester and Log4j
Hi -
I am running into a strange NoSuchMethodError when using
the latest version 1.7 of Digester with the version 1.2.9
of Log4j. I have a very simple digester ruleset (but I
think that is irrelevant). The version of commons-beanutils
is the latest I could download from Jakarta.
Beanutils seems to be invoking an undefined method in
org.apache.log4j.Category. I call this strange because
when I repackage the classes com.bajji.sm.ems.* into
the default package the error disappears. This gives me
an impression that this may have to do with class loading.
If you have any clues to debugging this problem, pl
let me know. I 'd immensely appreciate it since I have now
spent a couple of days trying to figure this out.
Thanks,
/rk_
//...
DEBUG MethodUtils Found straight match: public void org.apache.commons
.digester.xmlrules.DigesterRuleParser.add(org.apache.commons.digester.
Rule)^M
^M
ERROR Digester 12:51:17 [main] (?:?): commons.digester.Digester^M
ERROR Digester End event threw error^M
java.lang.NoSuchMethodError: org.apache.log4j.Category: method log(Lja
va/lang/String;Lorg/apache/log4j/Level;Ljava/lang/Object;Ljava/lang/Th
rowable;)V not found^M
at org.apache.commons.beanutils.MethodUtils.getMatchingAccessibleM
ethod(Compiled Code)^M
at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUti
ls.java:209)^M
at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:21
6)^M
at org.apache.commons.digester.Rule.end(Compiled Code)^M
at org.apache.commons.digester.Digester.endElement(Compiled Code)^
M
at org.apache.crimson.parser.Parser2.maybeElement(Compiled Code)^M
at org.apache.crimson.parser.Parser2.content(Compiled Code)^M
at org.apache.crimson.parser.Parser2.maybeElement(Compiled Code)^M
at org.apache.crimson.parser.Parser2.content(Compiled Code)^M
at org.apache.crimson.parser.Parser2.maybeElement(Compiled Code)^M
at org.apache.crimson.parser.Parser2.parseInternal(Compiled Code)^
M
at org.apache.crimson.parser.Parser2.parse(Parser2.java:305)^M
at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.jav
a:433)^M
at org.apache.commons.digester.Digester.parse(Digester.java:1666)^
M
at org.apache.commons.digester.xmlrules.FromXmlRuleSet$URLXMLRules
Loader.loadRules(FromXmlRuleSet.java:196)^M
at org.apache.commons.digester.xmlrules.FromXmlRuleSet.addRuleInst
ances(FromXmlRuleSet.java:175)^M
at org.apache.commons.digester.xmlrules.FromXmlRuleSet.addRuleInst
ances(FromXmlRuleSet.java:140)^M
at org.apache.commons.digester.Digester.addRuleSet(Digester.java:1
776)^M
at org.apache.commons.digester.xmlrules.DigesterLoader.createDiges
ter(DigesterLoader.java:79)^M
at com.bajji.sm.ems.classifier.dictionary.Dictionary.load(Dictiona
ry.java:92)^M
at com.bajji.sm.ems.classifier.dictionary.SnmpTrapDictionary.<init
>(SnmpTrapDictionary.java:61)^M
at com.bajji.sm.ems.classifier.dictionary.SnmpTrapDictionary.<clin
it>(SnmpTrapDictionary.java:36)^M
--
_______________________________________________
Search for businesses by name, location, or phone number. -Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Re[2]: Strange problem with Digester and Log4j
Posted by Simon Kitching <sk...@apache.org>.
On Wed, 2006-03-29 at 12:36 +0200, Christian Hufgard wrote:
> Hi Simon,
>
> > Most of those problems never existed. That page is just wrong in many
> > places.
>
> This is -erm- weird. The information seems to be quit reasonable, is
> it just a try from the log4j author to prevent people from using
> commons-logging?
>
Ceki is a very bright guy, and has done some great work with logging.
He's also come up with some nice ideas for SLF4J that may well influence
upcoming releases of commons-logging. However that particular page
really is misleading.
It would appear that the article was written shortly after having
identified a bug in Tomcat that was obscured by a misconfiguration of
logging. I've been there myself; computers can be damn frustrating
things. However that never leads to a fair and balanced view.
Much of the article is arguing against using JCL for *applications*.
That's quite reasonable, and I personally agree (though some do not;
Tomcat uses JCL for example). However the article isn't clear that these
arguments apply to only "application" scenarios (and not to "library"
code); it appears to be arguing against using JCL at all which is wrong.
I don't know if this was just accidental implication when writing or if
Ceki hadn't realised the critical difference between libraries and
applications when writing this.
The bits about JCL being a "lowest common denominator" lib are true.
Again, though, this is about *applications* vs *libraries*. For apps,
JCL adds complexity for a dubious gain - agreed. However for libraries,
you just *cannot* bind to a specific concrete lib; a wrapper of some
sort is the only sane option.
The bits about "wrappers increase the complexity" are true. So for apps,
don't use wrappers. However for *libraries* you don't have any option.
The stuff complaining about "auto-discovery" (which is about 50%) is
only partly relevant. A commons-logging.properties file really should be
used with each deployment - in which case no auto-discovery of the
library "type" occurs at all. Only if this file is missing is discovery
attempted. Agreed, the JCL documentation should have been clearer on
this issue.
Yes, there *are* some problems that can occur as a result of
classloading. However in many cases these are really limitations due to
the design of java rather than JCL. The options are to either reduce
functionality or document the necessary deployment rules. Unfortunately
commons-logging *is* a little light on documentation. And in the end,
there is little option - log4j is *not* applicable to libraries. The
SLF4J project *is* an alternative to JCL, but it achieves greater
reliability by sacrificing some significant functionality; that's ok but
should be pointed out.
The complaints about a lack of diagnostics in JCL to help investigations
is fair; JCL 1.1 (currently RC6) has this feature.
Complaints about JCL not supporting a NULL classloader (ie everything
loaded via the "bootloader") - well, ok it didn't support this. However
it's a pretty odd case. And like any other project, it just needed
someone to step up and make the changes; JCL 1.1 will handle this
(hopefully; there hasn't been a great herd of volunteers to test this,
and it's not testable on normal JVMs).
If you read Rodney Waldhof's article, you see he says very much the
same: don't use it for *apps*, but do use it for *libs*.
Referencing "The Bile Blog" in support of an argument really can't be
taken seriously :-)
So in summary, this page makes some good arguments for using a real
logging lib from applications. For libraries, it shows few real issues
and proposes no practical alternatives.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re[2]: Strange problem with Digester and Log4j
Posted by Christian Hufgard <ch...@gmx.de>.
Hi Simon,
> Most of those problems never existed. That page is just wrong in many
> places.
This is -erm- weird. The information seems to be quit reasonable, is
it just a try from the log4j author to prevent people from using
commons-logging?
--
Best regards,
Christian mailto:christian.hufgard@gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Strange problem with Digester and Log4j
Posted by Simon Kitching <sk...@apache.org>.
On Tue, 2006-03-28 at 23:20 +0200, Christian Hufgard wrote:
> Maybe you want to take a look at
> http://www.qos.ch/logging/thinkAgain.jsp , also you probably won't
> find a solution there, it is still an interesting page. ;)
>
> Can anyone confirm, if these problems are still present? And what can
> be done to preserve them?
Most of those problems never existed. That page is just wrong in many
places.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Strange problem with Digester and Log4j
Posted by Christian Hufgard <ch...@gmx.de>.
Hi rk_
> I am running into a strange NoSuchMethodError when using
> the latest version 1.7 of Digester with the version 1.2.9
> of Log4j. I have a very simple digester ruleset (but I
> think that is irrelevant). The version of commons-beanutils
> is the latest I could download from Jakarta.
> Beanutils seems to be invoking an undefined method in
> org.apache.log4j.Category. I call this strange because
> when I repackage the classes com.bajji.sm.ems.* into
> the default package the error disappears. This gives me
> an impression that this may have to do with class loading.
Maybe you have gone to classloader hell. I do not know, if this still
is a problem (we are using various components from commons and have
not found any problem yet) but it seems, that you might be there.
Maybe you want to take a look at
http://www.qos.ch/logging/thinkAgain.jsp , also you probably won't
find a solution there, it is still an interesting page. ;)
Can anyone confirm, if these problems are still present? And what can
be done to preserve them?
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: Strange problem with Digester and Log4j
Posted by Marco Mistroni <mm...@waersystems.com>.
Hello,
My 2 cents
I have following 'setups' that work fine
Digester 1.7
Beanutils 1.6
Logging-1.0.2
Logging-api-1.0.2
Digester 1.7
Beanutils 1.6
Log4j-1.2.7
Can you try 1.2.7?
One other thing: can you make suret hat , across the whole classpath, you
have ONLY 1 version of the above files?
I got similar problem and keep on bothering this list before realizing that
My claasspath was screwed up
HTH
marco
-----Original Message-----
From: Simon Kitching [mailto:skitching@apache.org]
Sent: 29 March 2006 11:30
To: Jakarta Commons Users List
Subject: Re: Strange problem with Digester and Log4j
hi rk,
That is pretty weird.
BeanUtils is definitely not calling any such method directly. BeanUtils
only uses commons-logging. It looks to me like the JVM is doing some
major "code optimisation" at runtime, effectively replacing the sequence
MethodUtils.getMatchingAccessableMethod
--> commons.logging.Log.trace(msg)
--> log4j.Category.log(fqdn, Level.TRACE, msg, null)
by
MethodUtils.getMatchingAccessableMethod
--> log4j.Category.log.fqdn(....)
ie optimising out commons-logging.
And it looks to me like it gets it wrong.
I can't think of any other explanation for this. BeanUtils only uses
commons-logging, never log4j direct. And commons-logging has never had
any problems with calling log4j.
Log4J 1.3 was considering phasing out the Category class. However the
1.2.x series hasn't changed anything in this area as far as I know (and
I think I'd know).
The fact that the problem disappears when the calling code is in the
"global package" is also extremely weird. I can't think of any
explanation for that at all. That shouldn't affect the way classloading
happens at all; ClassLoader objects don't really care about what package
they are loading their classes from. It certainly doesn't affect which
classloader will be used.
Classloader problems don't seem to explain this to me. Yes, there could
potentially be multiple versions of log4j floating around. However all
of them provide the same API, so shouldn't be able to trigger this
"NoSuchMethodError". In any case, digester uses logging before calling
beanutils, so if there was a problem it wouldn't pop up here.
Hmm..there are a few calls to log.trace there, and log4j1.2.12 and later
do support TRACE level. Commons-logging currently maps all calls to
TRACE level into calls to log4j's DEBUG level (as trace wasn't
previously available). Again, I can't see why this would affect anything
but if you do have log4j 1.2.12 or later in the classpath you might want
to replace it (or replace the older ones) so you don't get a mix of
pre-1.2.12 and post-1.2.12 log4j jars in the same classpath.
What JVM are you using? Could you try using a different JVM (eg the ibm
one instead of the sun one)?
Are you running this code as a stand-alone application, or inside some
kind of container (eg jboss)? If you're running in a container, maybe
try swapping between "child-first" and "parent-first" classloading
behaviour. I really don't think this will make any difference but....
The commons-logging-1.1RCx series has a "diagnostics" feature, but that
applies to the "setup" phase, not to the actual logging phase.
If you're really desperate then you might want to just disable logging.
The best way to do that is to add a file named
"commons-logging.properties" to the classpath containing this:
org.apache.commons.logging.Log=\
org.apache.commons.logging.impl.NoOpLog
That will use the built-in "no-op" logger instead of log4j which should
fix the problem for sure.
Regards,
Simon
On Wed, 2006-03-29 at 03:16 +0600, s r wrote:
>
> Hi -
>
> I am running into a strange NoSuchMethodError when using
> the latest version 1.7 of Digester with the version 1.2.9
> of Log4j. I have a very simple digester ruleset (but I
> think that is irrelevant). The version of commons-beanutils
> is the latest I could download from Jakarta.
>
> Beanutils seems to be invoking an undefined method in
> org.apache.log4j.Category. I call this strange because
> when I repackage the classes com.bajji.sm.ems.* into
> the default package the error disappears. This gives me
> an impression that this may have to do with class loading.
>
> If you have any clues to debugging this problem, pl
> let me know. I 'd immensely appreciate it since I have now
> spent a couple of days trying to figure this out.
>
> Thanks,
>
> /rk_
>
>
> //...
> DEBUG MethodUtils Found straight match: public void org.apache.commons
> .digester.xmlrules.DigesterRuleParser.add(org.apache.commons.digester.
> Rule)^M
> ^M
> ERROR Digester 12:51:17 [main] (?:?): commons.digester.Digester^M
> ERROR Digester End event threw error^M
> java.lang.NoSuchMethodError: org.apache.log4j.Category: method log(Lja
> va/lang/String;Lorg/apache/log4j/Level;Ljava/lang/Object;Ljava/lang/Th
> rowable;)V not found^M
> at org.apache.commons.beanutils.MethodUtils.getMatchingAccessibleM
> ethod(Compiled Code)^M
> at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUti
> ls.java:209)^M
> at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:21
> 6)^M
> at org.apache.commons.digester.Rule.end(Compiled Code)^M
> at org.apache.commons.digester.Digester.endElement(Compiled Code)^
> M
> at org.apache.crimson.parser.Parser2.maybeElement(Compiled Code)^M
> at org.apache.crimson.parser.Parser2.content(Compiled Code)^M
> at org.apache.crimson.parser.Parser2.maybeElement(Compiled Code)^M
> at org.apache.crimson.parser.Parser2.content(Compiled Code)^M
> at org.apache.crimson.parser.Parser2.maybeElement(Compiled Code)^M
> at org.apache.crimson.parser.Parser2.parseInternal(Compiled Code)^
> M
> at org.apache.crimson.parser.Parser2.parse(Parser2.java:305)^M
> at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.jav
> a:433)^M
> at org.apache.commons.digester.Digester.parse(Digester.java:1666)^
> M
> at org.apache.commons.digester.xmlrules.FromXmlRuleSet$URLXMLRules
> Loader.loadRules(FromXmlRuleSet.java:196)^M
> at org.apache.commons.digester.xmlrules.FromXmlRuleSet.addRuleInst
> ances(FromXmlRuleSet.java:175)^M
> at org.apache.commons.digester.xmlrules.FromXmlRuleSet.addRuleInst
> ances(FromXmlRuleSet.java:140)^M
> at org.apache.commons.digester.Digester.addRuleSet(Digester.java:1
> 776)^M
> at org.apache.commons.digester.xmlrules.DigesterLoader.createDiges
> ter(DigesterLoader.java:79)^M
> at com.bajji.sm.ems.classifier.dictionary.Dictionary.load(Dictiona
> ry.java:92)^M
> at com.bajji.sm.ems.classifier.dictionary.SnmpTrapDictionary.<init
> >(SnmpTrapDictionary.java:61)^M
> at com.bajji.sm.ems.classifier.dictionary.SnmpTrapDictionary.<clin
> it>(SnmpTrapDictionary.java:36)^M
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Strange problem with Digester and Log4j
Posted by Simon Kitching <sk...@apache.org>.
hi rk,
That is pretty weird.
BeanUtils is definitely not calling any such method directly. BeanUtils
only uses commons-logging. It looks to me like the JVM is doing some
major "code optimisation" at runtime, effectively replacing the sequence
MethodUtils.getMatchingAccessableMethod
--> commons.logging.Log.trace(msg)
--> log4j.Category.log(fqdn, Level.TRACE, msg, null)
by
MethodUtils.getMatchingAccessableMethod
--> log4j.Category.log.fqdn(....)
ie optimising out commons-logging.
And it looks to me like it gets it wrong.
I can't think of any other explanation for this. BeanUtils only uses
commons-logging, never log4j direct. And commons-logging has never had
any problems with calling log4j.
Log4J 1.3 was considering phasing out the Category class. However the
1.2.x series hasn't changed anything in this area as far as I know (and
I think I'd know).
The fact that the problem disappears when the calling code is in the
"global package" is also extremely weird. I can't think of any
explanation for that at all. That shouldn't affect the way classloading
happens at all; ClassLoader objects don't really care about what package
they are loading their classes from. It certainly doesn't affect which
classloader will be used.
Classloader problems don't seem to explain this to me. Yes, there could
potentially be multiple versions of log4j floating around. However all
of them provide the same API, so shouldn't be able to trigger this
"NoSuchMethodError". In any case, digester uses logging before calling
beanutils, so if there was a problem it wouldn't pop up here.
Hmm..there are a few calls to log.trace there, and log4j1.2.12 and later
do support TRACE level. Commons-logging currently maps all calls to
TRACE level into calls to log4j's DEBUG level (as trace wasn't
previously available). Again, I can't see why this would affect anything
but if you do have log4j 1.2.12 or later in the classpath you might want
to replace it (or replace the older ones) so you don't get a mix of
pre-1.2.12 and post-1.2.12 log4j jars in the same classpath.
What JVM are you using? Could you try using a different JVM (eg the ibm
one instead of the sun one)?
Are you running this code as a stand-alone application, or inside some
kind of container (eg jboss)? If you're running in a container, maybe
try swapping between "child-first" and "parent-first" classloading
behaviour. I really don't think this will make any difference but....
The commons-logging-1.1RCx series has a "diagnostics" feature, but that
applies to the "setup" phase, not to the actual logging phase.
If you're really desperate then you might want to just disable logging.
The best way to do that is to add a file named
"commons-logging.properties" to the classpath containing this:
org.apache.commons.logging.Log=\
org.apache.commons.logging.impl.NoOpLog
That will use the built-in "no-op" logger instead of log4j which should
fix the problem for sure.
Regards,
Simon
On Wed, 2006-03-29 at 03:16 +0600, s r wrote:
>
> Hi -
>
> I am running into a strange NoSuchMethodError when using
> the latest version 1.7 of Digester with the version 1.2.9
> of Log4j. I have a very simple digester ruleset (but I
> think that is irrelevant). The version of commons-beanutils
> is the latest I could download from Jakarta.
>
> Beanutils seems to be invoking an undefined method in
> org.apache.log4j.Category. I call this strange because
> when I repackage the classes com.bajji.sm.ems.* into
> the default package the error disappears. This gives me
> an impression that this may have to do with class loading.
>
> If you have any clues to debugging this problem, pl
> let me know. I 'd immensely appreciate it since I have now
> spent a couple of days trying to figure this out.
>
> Thanks,
>
> /rk_
>
>
> //...
> DEBUG MethodUtils Found straight match: public void org.apache.commons
> .digester.xmlrules.DigesterRuleParser.add(org.apache.commons.digester.
> Rule)^M
> ^M
> ERROR Digester 12:51:17 [main] (?:?): commons.digester.Digester^M
> ERROR Digester End event threw error^M
> java.lang.NoSuchMethodError: org.apache.log4j.Category: method log(Lja
> va/lang/String;Lorg/apache/log4j/Level;Ljava/lang/Object;Ljava/lang/Th
> rowable;)V not found^M
> at org.apache.commons.beanutils.MethodUtils.getMatchingAccessibleM
> ethod(Compiled Code)^M
> at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUti
> ls.java:209)^M
> at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:21
> 6)^M
> at org.apache.commons.digester.Rule.end(Compiled Code)^M
> at org.apache.commons.digester.Digester.endElement(Compiled Code)^
> M
> at org.apache.crimson.parser.Parser2.maybeElement(Compiled Code)^M
> at org.apache.crimson.parser.Parser2.content(Compiled Code)^M
> at org.apache.crimson.parser.Parser2.maybeElement(Compiled Code)^M
> at org.apache.crimson.parser.Parser2.content(Compiled Code)^M
> at org.apache.crimson.parser.Parser2.maybeElement(Compiled Code)^M
> at org.apache.crimson.parser.Parser2.parseInternal(Compiled Code)^
> M
> at org.apache.crimson.parser.Parser2.parse(Parser2.java:305)^M
> at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.jav
> a:433)^M
> at org.apache.commons.digester.Digester.parse(Digester.java:1666)^
> M
> at org.apache.commons.digester.xmlrules.FromXmlRuleSet$URLXMLRules
> Loader.loadRules(FromXmlRuleSet.java:196)^M
> at org.apache.commons.digester.xmlrules.FromXmlRuleSet.addRuleInst
> ances(FromXmlRuleSet.java:175)^M
> at org.apache.commons.digester.xmlrules.FromXmlRuleSet.addRuleInst
> ances(FromXmlRuleSet.java:140)^M
> at org.apache.commons.digester.Digester.addRuleSet(Digester.java:1
> 776)^M
> at org.apache.commons.digester.xmlrules.DigesterLoader.createDiges
> ter(DigesterLoader.java:79)^M
> at com.bajji.sm.ems.classifier.dictionary.Dictionary.load(Dictiona
> ry.java:92)^M
> at com.bajji.sm.ems.classifier.dictionary.SnmpTrapDictionary.<init
> >(SnmpTrapDictionary.java:61)^M
> at com.bajji.sm.ems.classifier.dictionary.SnmpTrapDictionary.<clin
> it>(SnmpTrapDictionary.java:36)^M
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org