Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

The jar synchronization issue seems to be out of hand.

 
John Wooten
Greenhorn
Posts: 7
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am trying to get httpunit testing to work. I am running NekoHTML 1.9.14. I get an error
java.lang.NoSuchMethodError: org.apache.xerces.parsers.DOMParser.<init>(Lorg/apache/xerces/xni/parser/XMLParserConfiguration;)V
at com.meterware.httpunit.parsing.NekoDOMParser.<init>(NekoDOMParser.java:130)
at com.meterware.httpunit.parsing.NekoDOMParser.newParser(NekoDOMParser.java:103)
at com.meterware.httpunit.parsing.NekoHTMLParser.parse(NekoHTMLParser.java:47)
at com.meterware.httpunit.HTMLPage.parse(HTMLPage.java:271)
at com.meterware.httpunit.WebResponse.getReceivedPage(WebResponse.java:1301)
...
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

Now, my classpath(in eclipse) is:

<classpath>
<classpathentry kind="src" path="src"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="src" path="/sc_core"/>
<classpathentry kind="lib" path="lib/junit.jar"/>
<classpathentry kind="lib" path="lib/log4j-1.2.7.jar"/>
<classpathentry kind="src" path="/sc_adapters"/>
<classpathentry kind="src" path="/sc_businessobjects"/>
<classpathentry kind="src" path="/sc_queueing"/>
<classpathentry kind="src" path="/sc_regulator"/>
<classpathentry kind="lib" path="/ThirdPartyLibraries/commons-digester.jar"/>
<classpathentry kind="lib" path="/ThirdPartyLibraries/commons-collections.jar"/>
<classpathentry kind="lib" path="/ThirdPartyLibraries/commons-beanutils.jar"/>
<classpathentry kind="src" path="/sc_workflow"/>
<classpathentry kind="src" path="/sc_datamanipulation"/>
<classpathentry kind="lib" path="/ThirdPartyLibraries/hibernate2.jar"/>
<classpathentry kind="lib" path="/ThirdPartyLibraries/j2ee-1.0.jar"/>
<classpathentry combineaccessrules="false" kind="src" path="/sc_wfeditor"/>
<classpathentry kind="lib" path="/ThirdPartyLibraries/mysql-connector-java-3.0.14-production-bin.jar"/>
<classpathentry combineaccessrules="false" kind="src" path="/sc_utilities"/>
<classpathentry combineaccessrules="false" kind="src" path="/sc_wfserver_http"/>
<classpathentry kind="lib" path="/ThirdPartyLibraries/jcommon-1.0.10.jar"/>
<classpathentry kind="lib" path="/ThirdPartyLibraries/jfreechart-1.0.6.jar"/>
<classpathentry combineaccessrules="false" kind="src" path="/sc_taglibrary"/>
<classpathentry combineaccessrules="false" kind="src" path="/sc_entity"/>
<classpathentry kind="lib" path="/ThirdPartyLibraries/commons-jxpath-1.1.jar"/>
<classpathentry kind="lib" path="/ThirdPartyLibraries/httpunit.jar" sourcepath="/Users/woo/Development/workspaces/sc_workspace/httpunit-1.7/src"/>
<classpathentry kind="lib" path="/ThirdPartyLibraries/js-14.jar"/>
<classpathentry kind="lib" path="/ThirdPartyLibraries/nekohtml.jar"/>
<classpathentry kind="lib" path="/ThirdPartyLibraries/xercesImpl.jar"/>
<classpathentry kind="output" path="bin"/>
</classpath>


I have looked int xercesImpl and there is definitely a class "org.apache.xerces.parsers.DOMParser". This is the version 2+ of xercesImpl that was stated to be needed for nekohtml. The method message isn't clear to me. What else is missing? Why should this be so hard? If someone is trying to do httpunit testing, why not give a list or a bundle of the necessary jars?

 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd assume a version issue.

The HttpUnit distribution includes the jars it requires--getting this list is as simple as looking at the directory. Its dependencies are also listed in its pom, or via sites like mvnrepository.com. When you start mixing-and-matching versions, you're pretty much on your own, and you'll run into errors like you've posted fairly often: you go outside the bounds of what's required, it's your responsibility to manage it.
 
John Wooten
Greenhorn
Posts: 7
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Was using files from distribution. Finally found problem was that I needed to put xerxes jar BEFORE neko jar. Got that by trial and error.

One difficulty is that jar versions aren't identified sometimes. People say use same versions, but what does that mean if they aren't labeled? Found neko version using version Version.getVersion method. Not all have such.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
May be in Manifest file, other times you just have to be aware what you're using, and either rename locally, or wing it. Issues like this are one reason Maven and Ant+Ivy exist.
 
Mark Wuest
Ranch Hand
Posts: 88
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Newton wrote:May be in Manifest file, other times you just have to be aware what you're using, and either rename locally, or wing it. Issues like this are one reason Maven and Ant+Ivy exist.


I'm a little confused by the solution OP found here: unless HttpUnit came with an unusable version of xerces in it's own jar or something, changing the order of the classpath doesn't seem like it should fix this?

I'm getting the same error with hapi (an hl7 message parser from http://hl7api.sourceforge.net/).

On a whim, I tried changing the order in .classpath (also using myeclipse like OP). No cigar. I tried using xercesImpl.jar that came bundled with the hapi download and also tried the latest from Apache. Yeah, I'm grasping at straws here. :)

'Any other thoughts as to why it's not finding this?

Well, for completeness', here's my exciting and wonderful .classpath:



Thanks,

Mark
 
Mathieu Fortin
Greenhorn
Posts: 16
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What jdk versions are you using? Older jdks included xerces and xalan version and a lot of conflicts were experienced. Packages were renamed starting in 1.5 (com.sun.org.apache.xerces) to remove any possibility of conflicts.

Mathieu
http://simpleadn.blogspot.com
 
Mark Wuest
Ranch Hand
Posts: 88
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mathieu Fortin wrote:What jdk versions are you using? Older jdks included xerces and xalan version and a lot of conflicts were experienced. Packages were renamed starting in 1.5 (com.sun.org.apache.xerces) to remove any possibility of conflicts.


Thanks - my JDK is 1.6 building 1.5 compatible files to run on Weblogic 9.1 on a 1.5 JRE.
 
Mark Wuest
Ranch Hand
Posts: 88
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Update: I did get Weblogic (we're still on 9.1, BTW) to override the classpath loading order by putting this in weblogic.xml:



This, of course, caused other incompatibility issues with the app and WLS. I'm going to try it on a more current version of WLS.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic