commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marco Mistroni" <mmistr...@waersystems.com>
Subject RE: Strange problem with Digester and Log4j
Date Wed, 29 Mar 2006 11:41:52 GMT
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


Mime
View raw message