Ich habe einen Jax-WS-Dienst in einer eigenständigen Serveranwendung veröffentlicht. Dieser Dienst verwendet MTOM Dokumente erhaltenJAX-WS-Fehleränderungen im mtom-Dienst, wenn die Protokollierung über SOAPHandler aktiviert ist
Wie in der Antwort auf diese Frage beraten:
Tracing XML request/responses with JAX-WS
ich einen Handler für Seife Nachricht verwenden, für den Dienst anmelden, wie unten:
public boolean handleMessage(SOAPMessageContext smc){
performLoggingActions(smc);
return true;
}
Die Logger-Methode ist wie folgt:
private void performLoggingActions(SOAPMessageContext smc) {
ByteArrayOutputStream bout = null;
try {
Boolean isOutBound = (Boolean) smc.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
SOAPMessage message = smc.getMessage();
//More stuff
} catch (Exception e) {
logger.error(String.format("Error in logSoapMessage! Error: %s ", e.getMessage()), e);
} finally {
IOUtils.closeQuietly(bout);
}
}
Wenn der Client eine gültige Anforderung sendet, gibt es kein Problem bei der Protokollierung. Alles wird wie erwartet protokolliert.
Wenn ich jedoch eine ungültige Inhalts-ID in Anforderung über SOAP UI sende, schlägt die Protokollierung in Zeile fehl SOAPMessage message = smc.getMessage(); und ich habe den unten Fehler:
Error in logSoapMessage! Error: No such MIME Part: Part=5
java.lang.IllegalStateException: No such MIME Part: Part=5
at com.sun.xml.internal.org.jvnet.mimepull.DataHead.read(DataHead.java:138)
at com.sun.xml.internal.org.jvnet.mimepull.MIMEPart.read(MIMEPart.java:85)
Das Problem ist, wenn dies der Fall ist, wird die Meldung nicht auf Service-Level propagieren und der Service antwortet dem Client mit folgenden Fehler:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope">
<faultcode>S:Server</faultcode>
<faultstring>unexpected XML tag. expected: somenamespace but found: {http://www.w3.org/2004/08/xop/include}Include</faultstring>
</S:Fault>
</S:Body>
</S:Envelope>
Als ich Deaktivieren Sie die Soap-Protokollierung und senden Sie eine Fehleranforderung. Die Nachricht wird an die @ WebService-Annotation-Klasse an die Service-Ebene weitergegeben. Beim Versuch, den mtom-Inhalt zu lesen, erhalte ich ähnliche Erwartungen. jedoch der Fehler in diesem Fall wird in der Antwort als Fehler Zeichenfolge wider:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope">
<faultcode>S:Server</faultcode>
<faultstring>No such MIME Part: Part=5</faultstring>
</S:Fault>
</S:Body>
</S:Envelope>
ich den gleichen Fehler unabhängig von der Existenz der Logging-Handler erwartet.
Wie Sie sehen, bin ich alle Ausnahmen im Logging-Handler abfangen, aber die Service-Antwort ändert sich entsprechend der Existenz des Logging-Handler.
Ich mache etwas falsch? Meine Anforderung ist, den gleichen Fehler mit und ohne Logging-Handler zu bekommen.
Grüße
EDIT: Gesamter Stack-Trace des Fehlers hinzugefügt:
Error in logSoapMessage! Error: No such MIME Part: Part=5
java.lang.IllegalStateException: No such MIME Part: Part=5
at com.sun.xml.internal.org.jvnet.mimepull.DataHead.read(DataHead.java:138)
at com.sun.xml.internal.org.jvnet.mimepull.MIMEPart.read(MIMEPart.java:85)
at com.sun.xml.internal.ws.encoding.MIMEPartStreamingDataHandler$StreamingDataSource.getInputStream(MIMEPartStreamingDataHandler.java:98)
at com.sun.xml.internal.org.jvnet.staxex.Base64Data.get(Base64Data.java:315)
at com.sun.xml.internal.org.jvnet.staxex.Base64Data.length(Base64Data.java:357)
at com.sun.xml.internal.ws.encoding.MtomCodec$MtomXMLStreamReaderEx.getTextCharacters(MtomCodec.java:533)
at com.sun.istack.internal.XMLStreamReaderToContentHandler.handleCharacters(XMLStreamReaderToContentHandler.java:244)
at com.sun.istack.internal.XMLStreamReaderToContentHandler.bridge(XMLStreamReaderToContentHandler.java:155)
at com.sun.xml.internal.ws.message.stream.StreamMessage.writePayloadTo(StreamMessage.java:375)
at com.sun.xml.internal.ws.message.stream.StreamMessage.writeTo(StreamMessage.java:460)
at com.sun.xml.internal.ws.message.AbstractMessageImpl.readAsSOAPMessage(AbstractMessageImpl.java:196)
at com.sun.xml.internal.ws.handler.SOAPMessageContextImpl.getMessage(SOAPMessageContextImpl.java:82)
at com.ibtech.smg.esb.jaxws.handler.JAXWSSOAPLoggingHandler.performLoggingActions(JAXWSSOAPLoggingHandler.java:54)
at com.ibtech.smg.esb.jaxws.handler.JAXWSSOAPLoggingHandler.handleMessage(JAXWSSOAPLoggingHandler.java:36)
at com.ibtech.smg.esb.jaxws.handler.JAXWSSOAPLoggingHandler.handleMessage(JAXWSSOAPLoggingHandler.java:1)
at com.sun.xml.internal.ws.handler.HandlerProcessor.callHandleMessage(HandlerProcessor.java:295)
at com.sun.xml.internal.ws.handler.HandlerProcessor.callHandlersRequest(HandlerProcessor.java:138)
at com.sun.xml.internal.ws.handler.ServerSOAPHandlerTube.callHandlersOnRequest(ServerSOAPHandlerTube.java:136)
at com.sun.xml.internal.ws.handler.HandlerTube.processRequest(HandlerTube.java:118)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:639)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:598)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:583)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:480)
at com.sun.xml.internal.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:312)
at com.sun.xml.internal.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:606)
at com.sun.xml.internal.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:257)
at com.sun.xml.internal.ws.transport.http.server.WSHttpHandler.handleExchange(WSHttpHandler.java:108)
at com.sun.xml.internal.ws.transport.http.server.WSHttpHandler.handle(WSHttpHandler.java:93)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:90)
at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:96)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:93)
at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:690)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:90)
at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:662)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627)
at java.lang.Thread.run(Thread.java:809)
Ich habe die gesamte Stack-Trace hinzugefügt. Wie Sie sehen können, ist die Zeile, die Sie anführen, gedruckt. Die Ausnahme tritt ab Zeile SOAPMessage message = smc.getMessage(); – simpleusr
Fügen Sie einfach 'throw e' zu Ihrem catch-Block hinzu und sehen Sie. Das sollte die ursprüngliche Ausnahme auf den Client zurückwerfen. – Gautam
Hallo, ich dachte schon, dass Option, aber öffentliche Boolean handleMessage (C-Kontext) -Methode in javax.xml.ws.handler.Handler Schnittstelle lässt keine Ausnahmen geworfen werden ... –
simpleusr