You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "aaron pieper (JIRA)" <ji...@apache.org> on 2010/01/05 20:39:54 UTC
[jira] Created: (CXF-2602) LoggingOutInterceptor does not always
log the same SOAP envelope which is returned from the service
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.
[jira] Commented: (CXF-2602) LoggingOutInterceptor does not always
log the same SOAP envelope which is returned from the service
Posted by "aaron pieper (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796829#action_12796829 ]
aaron pieper commented on CXF-2602:
-----------------------------------
I'm not savvy enough to create an isolated test case, since this is more of an architectural problem rather than a problem with a single class. However, a simple scenario would be that a bad interceptor in the "Marshal" step writes a lot of garbage to the XMLStreamWriter - that garbage should be logged. Does that seem like a valuable test case to you? If I can find a bare bones CXF test case to start from, which creates a phase interceptor chain and a CXF message and does all the basic stuff, I can adapt that test case to illustrate what I'm talking about.
One possible way for the LoggingOutInterceptor to be rearchitected, would be for it to replace the XmlStreamWriter, instead of replacing the OutputStream. If it did that, it could be moved late enough in the chain to capture any weirdness which occurrs in generating the SOAP envelope.
Here's the full list of "snipped" things - most of the stuff in the "pre-stream" step is proprietary code, but you should get the idea.
prepare-send [MessageSenderInterceptor, Soap11FaultOutInterceptor]
pre-stream [MtomFaultForceInterceptor, ExceptionScrubber, FaultDetailInterceptor, XsltOutInterceptor420x, XsltOutInter
ceptor411x, XsltOutInterceptor410x, LoggingOutInterceptor, StaxOutInterceptor]
pre-protocol [WebFaultOutInterceptor, SOAPHandlerFaultOutInterceptor]
write [SoapOutInterceptor]
pre-marshal [LogicalHandlerFaultOutInterceptor]
marshal [Soap11FaultOutInterceptorInternal]
post-marshal [LogicalHandlerFaultOutEndingInterceptor]
write-ending [SoapOutEndingInterceptor]
pre-stream-ending [Compat420xXsltOutEndingInterceptor, StaxOutEndingInterceptor]
prepare-send-ending [MessageSenderEndingInterceptor]
> 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.
[jira] Commented: (CXF-2602) LoggingOutInterceptor does not always
log the same SOAP envelope which is returned from the service
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Closed: (CXF-2602) LoggingOutInterceptor does not always log
the same SOAP envelope which is returned from the service
Posted by "aaron pieper (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
aaron pieper closed CXF-2602.
-----------------------------
Resolution: Not A Problem
Thanks, Daniel - moving the LoggingOutInterceptor earlier in the chain fixed the disparity. After moving the LoggingOutInterceptor ahead of everything else in the pre-stream, I was unable to duplicate the bug. As such, I'm marking the bug as "Not a problem".
As far as the bug in Soap11FaultOutInterceptorInternal, I'll look around to see if a bug report has been filed.
> 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.
[jira] Commented: (CXF-2602) LoggingOutInterceptor does not always
log the same SOAP envelope which is returned from the service
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796820#action_12796820 ]
Daniel Kulp commented on CXF-2602:
----------------------------------
Note: it could be possible that the LoggingOutInterceptor needs to be moved earlier in the chain. What is in the list of "snipped" things?
Also, has the bug in the Soap11FaultOutInterceptorInternal that you mentioned been fixed?
> 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.