cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-2602) LoggingOutInterceptor does not always log the same SOAP envelope which is returned from the service
Date Tue, 05 Jan 2010 19:57:54 GMT

    [ https://issues.apache.org/jira/browse/CXF-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796818#action_12796818
] 

Daniel Kulp commented on CXF-2602:
----------------------------------


Can a testcase for the logging issue be created?

The LoggingOutInterceptor needs to be BEFORE everything else in the chain to capture the output.
  It replaces the OutputStream that everything writes to with an OutputStream that records
what is being written.    Thus, if it's any later in the chain, it would not log anything.
  In particular, if it's after the StaxOutInterceptor, no XML would be logged as the StaxOutInterceptor
creates the XMLStreamWriter that writes to the output stream.   If the logging stream is not
there, the XMLStreamWriter would write to the "raw" stream and nothing would get logged.



> LoggingOutInterceptor does not always log the same SOAP envelope which is returned from
the service
> ---------------------------------------------------------------------------------------------------
>
>                 Key: CXF-2602
>                 URL: https://issues.apache.org/jira/browse/CXF-2602
>             Project: CXF
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 2.2.2
>            Reporter: aaron pieper
>            Priority: Minor
>
> I encountered a bug in my software, which was difficult to track down because the LoggingOutInterceptor
was not logging the SOAP envelope correctly. Because the LoggingOutInterceptor is placed before
several other CXF components in the interceptor chain, it is possible for the logged SOAP
envelope to be different from what actually gets sent out.
> More specifically, my phase interceptor chain looked like this:
> --------------------
>   pre-stream [(snip), LoggingOutInterceptor, StaxOutInterceptor]
>   pre-protocol [WebFaultOutInterceptor, SOAPHandlerFaultOutInterceptor]
>   write [SoapOutInterceptor]
>   pre-marshal [LogicalHandlerFaultOutInterceptor]
>   marshal [Soap11FaultOutInterceptorInternal]
>   post-marshal (snip)
> --------------------
> There was a bug in the Soap11FaultOutInterceptorInternal, which was stripping certain
namespaces from the response; so that the returned Soap Envelope looked like this:
> --------------------
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> 	<soap:Body>
> 		<ns1:Fault xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/">
> 			<faultcode>ns2:Receiver</faultcode>
> --------------------
> However, because the bug happened after the LoggingOutInterceptor, the LoggingOutInterceptor
logged a different Soap Envelope:
> --------------------
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> 	<soap:Body>
> 		<ns1:Fault xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/">
> 			<faultcode xmlns:ns2="http://www.w3.org/2003/05/soap-envelope">ns2:Receiver</faultcode>
> --------------------
> So according to the LoggingOutInterceptor, we sending out valid XML - but in fact, we
were sending out invalid XML, since the "ns2" namespace in our faultcode was being omitted.
> I think the LoggingOutInterceptor should be as late in the phase interceptor chain as
possible, so that it would always log what we're sending back to the user (minus any encryption.)
It seems like this will require a rearchitecting of the LoggingOutInterceptor (and possibly
some other components as well.) Hopefully these kinds of problems will be rare, so this disparity
won't come up often - so i think this is a low priority, but it would still be nice.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message