WS Exceptions

[DonUschi]

Moin,

bin grad ein wenig Ratlos bezüglich des Verhaltens meiner Webservice Schnittstelle.

Wenn ich lokal aufm Server deploye bekomme ich in SOAPUI wunderbar meine Selbstdefinierten Exceptions zurück.

Wenn ich auf unserem Testserver deploye bekomm ich nur n leeren Response. Im Serverlog steht dann was von SOAPFault und SOAP Exception.

Kann damit jemand was anfangen?

Gruß,

Uschi

Bearbeitet 26. April 2010 von DonUschi

[kingofbrain]

Das ist doch glasklar: das ist irgendein Fehler bei der Verarbeitung Deiner SOAP-Anfrage.

Für eine genauere Lösung brauchen wir eine genauere Fehlerbeschreibung? Wie sieht der Stacktrace der Exception aus, was steht in der Exception drin, usw.?

Schöne Grüße,

Peter

[DonUschi]

dachte das wäre ganz glasklar nen configurationsproblem.

denn das passiert ja nur im exception fall. normale ergebnisse, da bekomme ich in beiden fällen n sauberen response. trotzdem hier der stacktrace:

Private Paste - Pastie

[flashpixx]

Bitte verwende die Uploadfunktion des Boards.

Was mir direkt ins Auge springt, wenn ich den Trace lese:

de.projectbla.backend.core.service.UserCoreException: Permission denied.

Wobei es nun schwer wird, eine sinnvolle Interpretation zu finden, da wir das Projekt und die Systeme nicht kennen. Letztendlich besagt die Meldung, dass eben nicht genügend Rechte existieren.

[DonUschi]

genau, das ist auch gut so, es soll ne Exception geschmissen werden. Das passiert auch, doch SOAP kann daraus keine Exception machen die nu als Response verschickt wird. Lokal klappt das! Da bekomm ich als Response ganz korrekt die UserCoreException - permission denied.

Vom Testserver bekomm ich nen 0Byte Response und in den Serverlogs findet sich das eben geastete.

[flashpixx]

Das passiert auch, doch SOAP kann daraus keine Exception machen die nu als Response verschickt wird.

Lokal klappt das!

Ich kann hier nur blind raten: Wenn Du lokal testest benutzt Du den gleichen Klassenstamm, d.h. beide Komponenten greifen auf identische Klassen zu. Wenn Du das über das Netz machst, weiß eben der Sender nicht, wie er mit der Exception umzugehen hat, d.h. eine Exception ist auch "nur" ein Objekt, wenn Du das aber über das Netz versenden willst, musst Du es serialisieren, d.h. Du musst Serializable für Deine eigenen Exceptions implementieren und natürlich müssen sowohl Sender wie Empfänger über die Exceptionklassen verfügen.

Ist leider nur eine Vermutung, es fehlt halt wenn ein passender Codeauszug. Da aber die Exception im lokalen Fall geworfen wird, würde ich einfach darauf tippen, dass sie nicht übertragen wird.

edit: Natürlich muss alles was an der Exception hängt auch serialisiert werden, damit man sie vollständig wieder herstellen kann

Bearbeitet 26. April 2010 von flashpixx
edit

[DonUschi]

meine exception erbt von exception welches serializable implementiert. ne sid gibts auch und die exception wird natürlich über die wsdl bekannt gemacht, sonst würd das lokal ja auch garnicht funktionieren.

ich greif ja auch mit nem client auf meinen lokalen jboss zu. die haben nix miteinander am hut, von wegen gleiche code basis usw.

[kingofbrain]

Servus,

ich würde ähnlich wie flashpixx auf ein Classpath-Problem tippen. Mich hat aber eher die folgende Zeile stutzig gemacht:

Caused by: java.lang.IllegalStateException: Failed to load javax.xml.soap.MessageFactory:

Gibt es noch weitere "Caused by:"-Angaben im Log bei diesem Fehler?

Schöne Grüße,

Peter

Edith hat grad noch was dazwischengerufen: vielleicht ist es kein Classpath-, sondern ein Classloader-Problem. Die o.g. Klasse javax.xml.soap.MessageFactory ist ab JDK 6 im JDK enthalten, davor war sie in der EE-API mit dabei. Vielleicht sendet der Server eine Version, die der Client nicht (nicht mehr) kennt.

Bearbeitet 26. April 2010 von kingofbrain

[DonUschi]

die ee-api liefer ich mit meinem ear aus.

jkd6 wird nicht genutzt.

weritere "caused by" angaben gibts nicht.

[flashpixx]

Fang doch einmal die Exception, die KingOfBrain genannt hat, ab und suche wo sie in Deinem Code genau auftritt.

Ich hatte ein ähnliches Problem mit der Annotation Definition meiner Klassen, die durch ein XSD Schema erzeugt wurden. Es lag ein Versionskonflikt bei den generierten Klassen vor, die neueren Komponenten konnten mit den alten Klassen nichts anfangen und umgekehrt. Ich meine die Fehlermeldung war sogar die gleiche. Bei mir trat die Exception nur auf, sobald eine ein Unmarshall auf die XML Daten gemacht wurde, geworfen wurde aber eine Exception aus dem Parser. Ich bin nach langer suche eben auf die Bemerkung in der Doku mit den Annotations gestoßen. Klassen einmal neu erstellt und es lief dann direkt.

[kingofbrain]

die ee-api liefer ich mit meinem ear aus.

Die werden doch vom JBoss (oder jedem anderen Java EE Application Server) schon mitgebracht. Vielleicht ist gerade das das Problem. Mach Dich mal mit dem Thema Classloading im JBoss vertraut, ist ein spannendes Thema und Ursache vieler schöner Fehler.

Peter

[DonUschi]

local wie remote jboss 5.1.0.GA. timestamps der /lib/endorsed/jbossws-native-saaj.jar wo sich die factory drin befindet stimmen überein.

jee api kann ich im jboss nicht finden.

[kingofbrain]

Dann musst du vielleicht reindebuggen. Ich denke immer noch, dass Classloading ein heißer Kandidat für den Fehler ist. Aber dazu musst Du Dich mit dem Thema ein wenig auskennen.

Peter

[DonUschi]

bin nochmal euren ratschlägen nachgegangen. habe debuggt.

message factory wird lokal 2 mal benutzt.

ich hatte euch eine fehlinfo gegeben. jdk6 und javaee-api5 wird genutzt. das heißt das ganze ist doppelt vorhanden. beim debuggen hab ich dann gesehen, dass doch tatsächlich beide klassen genutzt werden!

wo ich überhaupt nicht drauf klar komme (das ist wohl das schöne thema classloading): com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl

soll in der message factory geladen werden. tjo wenn ich dann aber mal debugge, sehe ich was? org.jboss.ws.core.soap.MessageFactoryImpl aus jboss/client/jbossws-native-core.jar

[DonUschi]

warum die MessageFactory nu aus JDK und javaee-api im stacktrace vorkommen weiss ich imme rnoch nicht.

wohl aber warum es nun geht. der remote server wurde gestartet mit:

-Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl

Da kann der JBoss dann natürlich nicht die Implementierung finden die der JBoss mitbringt.

[kingofbrain]

Deine (nicht formulierte) Frage zum Classloading war wahrscheinlich folgende: Warum meckert die Runtime wegen der Klasse, die heißt doch genau so? Der Grund (den wir Entwickler gerne verdrängen), ist, dass eine Klasse zur Laufzeit durch ihren vollqualifizierten Namen *und* den Classloader definiert ist. Da man bei Java EE mit dem Classloading im spezifizierten Standardfall vom Parent First Ansatz aus Java SE abweicht (damit jedes Archiv seine eigenen Klassen mitbringen kann, ohne mit anderen Archiven zu kollidieren), kann es hier beim Optimieren (macht der JBoss gerne und weicht damit auch in der Grundkonfiguration von der Java EE Spec ab) zu Classloadingfehlern kommen.

Aber hier hilft wirklich die genaue Beschäftigung mit Classloading allgemein und im JBoss im Speziellen. Dauert zwar ein bisschen, bis man es geblickt hat, aber es lohnt sich.

Schöne Grüße,

Peter