Catching webservice exception with CXF: NoClassDefFoundError: SOAPFaultBuilder
Asked Answered
J

2

6

I've been using Apache CXF wsdl2java generated code to call methods from a webservice for some time now, which so far has been working fine.. The problem I'm having is that when the webservice (implemented just down the hall from me) legitimately throws a soap exception, CXF comes up with the following Error message:

Could not initialize class com.sun.xml.internal.ws.fault.SOAPFaultBuilder

I'm using Ubuntu 9.04, OpenJDK (IcedTea6 1.4.1) 6b14-1.1.1-0ubuntu11, Maven2 and CXF 2.2.3. I'm currently at a loss about how to resolve this problem, as the code and setup I'm using seems trivially simple.. Anyone able to point me in the right direction here? Let me know if I can post any further details..

This is the full stacktrace returned:

java.lang.NoClassDefFoundError: Could not initialize class com.sun.xml.internal.ws.fault.SOAPFaultBuilder
    at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:107)
    at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
    at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
    at $Proxy36.downloadPDB(Unknown Source)
    at path.to.my.code.downloadInvalidFileID(SingleMethodTest.java:64)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:616)
    at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
    at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
    at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
    at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
    at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
    at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
    at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
    at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
    at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
    at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
    at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
    at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
    at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
    at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
    at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
    at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:616)
    at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
    at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
Jd answered 29/9, 2009 at 20:26 Comment(3)
There's a "can I run under Java6" entry in the CXSFFAQ, have you checked that? cxf.apache.org/faq.html#FAQ-FrequentlyAskedQuestionsWatford
Hmm, thanks. I missed that note, and have now added com.sun.xml.bind jaxb-impl & jaxb-xjc in maven.. But so far no luck / change.. I'll work in this some more..Jd
No luck it seems: still the same stacktrace.. Is there anything I need to exclude using Maven perhaps?Jd
S
3

There are two interesting things about that stack trace:

1) It is having problems finding an SAAJ implementation. Probably adding saaj-impl.jar to the classpath might resolve that.

2) It's not using CXF at all. It's using the Sun JAX-WS reference implementation that's built into the jre. Thus, it looks like the cxf jars aren't being picked up at all.

Sarah answered 30/9, 2009 at 18:23 Comment(2)
Hmm interesting (well spotted!).. I'll look into this first thing tomorrow morning!Jd
Thanks, adding the cxf dependency did the trick! Never got around to adding cxf as a dependency, as the code seemed to work without it.. Silly me.Jd
D
5

Had similar problem when we're switching from Ant to Maven. We use Sun JDK 1.6u20.

We've missed these libraries in maven-assembled war's:

jaxws-api jaxws-rt jaxws-tools

After adding them all works as it had worked before. Hope this will help someone!

Demure answered 17/1, 2011 at 9:31 Comment(0)
S
3

There are two interesting things about that stack trace:

1) It is having problems finding an SAAJ implementation. Probably adding saaj-impl.jar to the classpath might resolve that.

2) It's not using CXF at all. It's using the Sun JAX-WS reference implementation that's built into the jre. Thus, it looks like the cxf jars aren't being picked up at all.

Sarah answered 30/9, 2009 at 18:23 Comment(2)
Hmm interesting (well spotted!).. I'll look into this first thing tomorrow morning!Jd
Thanks, adding the cxf dependency did the trick! Never got around to adding cxf as a dependency, as the code seemed to work without it.. Silly me.Jd

© 2022 - 2024 — McMap. All rights reserved.