2017-08-28 8 views
0

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) 

Antwort

0

Könnten Sie bitte den gesamten Stack-Trace und den Code in Ihrem SOAP-Handler einfügen? Wird diese Zeile in Ihren Protokollen gedruckt?
logger.error(String.format("Error in logSoapMessage! Error: %s ", e.getMessage()), e);

+0

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

+0

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

+0

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

Verwandte Themen