[JAX-WS] Subklassen von WebServiceException fangen

Java-Forum Jakarta EE (Java EE)
1

Hi,

wir stehen gerade bei einem Problem bei JAX-WS, genauer gesagt beim Exception Handling.
Im konkreten Fall müssen wir (fürs Erste) zwischen einer com.sun.xml.ws.client.ClientTransportException (Service nicht erreichbar) und einer com.sun.xml.ws.fault.ServerSOAPFaultException (z.B. fehlerhafte Schema Validation) unterscheiden. Das Problem hierbei ist, dass wir die Imports nicht definieren können, da der Pfad nicht aufgelöst wird. Als Workaround habe ich bisher den Weg gefunden, die Elternklasse javax.xml.ws.WebServiceException zu catchen, hier kann aber keine differenzierte Betrachtung der Exception erfolgen. (Eine Schema Validation sollte natürlich im Vorfeld schon von der Eingabe abgefangen sein, darauf möchte ich mich aber nicht verlassen).

Dem Benutzer soll nach Spezifikation angezeigt werden, ob der Service nicht erreichbar ist oder ein anderer Fehler vorliegt. Wir könnten jetzt natürlich anfangen auf den Wortlaut der Fehlermeldung zu reagieren, aber… das kann doch nicht der Weg sein. :rolleyes:

Als Problem sehe ich hier, dass Sun eine API implementiert und Exceptions aus seiner internal API nach oben wirft, die ich nicht explizit catchen kann. Stand jemand von euch schon einmal vor diesem Problem und hat einen Lösungsvorschlag?

Viele Grüße,
Tim

2

Geht ein Stringvergleich auf den Klassennamen?

catch(WebServiceException wse) {
    String exceptionClass = wse.getClass().getName();

    if (exceptionClass.equals("Lcom.sun.xml.ws.client.ClientTransportException") {
        // ...
    } else if (exceptionClass.equals("Lcom.sun.xml.ws.fault.ServerSOAPFaultException") {
        // ...
    }
}
3

Kann es sein, dass Du Dich bei den Packages vertan hast? Meinst Du nicht eher die folgenden beiden?:
[ul]
[li]com.sun.xml**.internal**.ws.client.ClientTransportException[/li][li]com.sun.xml**.internal**.ws.fault.ServerSOAPFaultException[/li][/ul]
Die sind zwar in einem internal Package. Das heißt aber nicht, dass man sie nicht nutzen kann. Das heißt nur, dass keine Kompatibilität mit neueren Releases garantiert wird. Man darf sich also nicht beschweren, wenn man das Programm nach einem Update des JDK an der Stelle anpassen muss.

Ich habe beide o.g. Klassen jedenfalls problemlos importieren können. Auch ein Blick in die Klassen (mangels Quellcode nur die Bytecode-Ansicht) zeigt, dass sie public sind. Die Anzeige der Typhierarchie von javax.xml.ws.WebServiceException zeigt die beiden o.g. Klassen als Subklassen an. Die von Dir genannten Klassen sind garnicht zu finden. Bin also ziemlich sicher, dass Du Dich beim Package vertan hast.

4

Btw, für die ServerSOAPFaultException gibt es eine Elternklasse javax.xml.ws.soap.SOAPFaultException, für die ClientTransportException leider nicht.

5

Hi,

Ja, der Vergleich auf Klassennamen wäre wahrscheinlich die bisher am wenigsten unsaubere Lösung, ganz glücklich bin ich damit auch nicht… Aber gut kommentiert und mit Zeitdruck… :smiley: An der Elternklasse der SoapFaultException kann ich mich auch mal versuchen, es stehen aber auch noch Tests mit anderen Fehlerarten aus.
@nillehammer : die beiden von dir genannten Klassen kann ich verwenden, im Catch Block lassen sie die Exception aber durch und fangen sie nicht. Eclipse schlägt mir diese beiden auch in der Code Completion vor, aber das sind definitiv die falschen. Die FQ-Classnames in meinem ersten Post habe ich so 1:1 aus dem Stacktrace kopiert. Bin (verständlicherweise) erst am Montag wieder auf der Arbeit, kann mich dann vielleicht mal an einem KSKB versuchen.

Viele Grüße und vielen Dank schon mal,

Tim

6

Hallo,

das Problem hat sich übrigens erledigt. Der Schema Validation Error wird von der Gegenseite (also dem SOAP Server) explizit geworfen, von daher ist die Lösung dann am Ende doch relativ einfach.

Vielen Dank und viele Grüße,
Tim

7

Btw, für die ServerSOAPFaultException gibt es eine Elternklasse javax.xml.ws.soap.SOAPFaultException, für die ClientTransportException leider nicht.