You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Gary Gregory (JIRA)" <ji...@apache.org> on 2010/01/06 20:45:54 UTC

[jira] Commented: (CXF-2594) No SOAP fault XML elements when a Fault is thrown in the output chain after SAAJOutInterceptor

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

Gary Gregory commented on CXF-2594:
-----------------------------------

I tested again today with the lasted from SVN to make sure the test behaved the same, it does. 

> No SOAP fault XML elements when a Fault is thrown in the output chain after SAAJOutInterceptor
> ----------------------------------------------------------------------------------------------
>
>                 Key: CXF-2594
>                 URL: https://issues.apache.org/jira/browse/CXF-2594
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.2.4, 2.2.6
>         Environment: java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Microsoft Windows [Version 6.0.6002]
> Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
> Java version: 1.6.0_16
> Java home: C:\Program Files\Java\jdk1.6.0_16\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows"
> Eclipse 3.6M4:
> Version: 3.6.0
> Build id: I20091210-1301
>            Reporter: Gary Gregory
>         Attachments: patch.txt
>
>
> The attached unit test runs on top of the 2.2.x SVN branch updated from SVN as of now.
> This ticket originated with this thread:
> http://old.nabble.com/Inflexible-fault-interceptor-chain--td26840876.html
> Which I replicate here with comments used for each step:
> Hi All:
> I need to apply an XSL transformation to messages coming out of CXF (our users configure what the XSL looks like.) For a normal (successful) message, I have an interceptor (during Phase.PRE_MARSHAL) that uses the DOM aspect of a message. That works great. BTW, I get to the DOM like this:
> Node node = (Node) message.getContent(List.class).get(0);
> That seems brittle, is there a safer way to get to an aspect of the message I can feed to javax.xml.transform?
> The real issue comes with fault messages because the fault chain uses an XMLStreamWriter<http://java.sun.com/javase/6/docs/api/javax/xml/stream/XMLStreamWriter.html>. The fault chain looks like this:
> Chain org.apache.cxf.phase.PhaseInterceptorChain@3015b303. Current flow:
>   setup [ServerPolicyOutFaultInterceptor]
>   prepare-send [MessageSenderInterceptor, Soap11FaultOutInterceptor]
>   pre-stream [LoggingOutInterceptor, XmlDeclOutInterceptor*, StaxOutInterceptor]
>   pre-protocol [WebFaultOutInterceptor, SOAPHandlerFaultOutInterceptor]
>   write [SoapOutInterceptor]
>   pre-marshal [LogicalHandlerFaultOutInterceptor]
>   marshal [Soap11FaultOutInterceptorInternal]
>   pre-stream-ending [StaxOutEndingInterceptor, TransformOutFaultInterceptor*]
>   prepare-send-ending [MessageSenderEndingInterceptor]
> FYI, the interceptors marked with * are our own:
> *         XmlDeclOutInterceptor forces an XML declaration to be written.
> *         TransformOutFaultInterceptor is where I thought I could transform the fault XML message.
> The XMLStreamWriter<http://java.sun.com/javase/6/docs/api/javax/xml/stream/XMLStreamWriter.html> looks like this:
> [StreamWriter: class com.ctc.wstx.sw.SimpleNsStreamWriter, underlying outputter: com.ctc.wstx.sw.ISOLatin1XmlWriter@1125cf44<ma...@1125cf44>
> The com.ctc.wstx.sw.ISOLatin1XmlWriter wraps a org.apache.cxf.io.CachedOutputStream, which in turns wraps:
> *         currentStream - LoadingByteArrayOutputStream
> *         flowThroughStream - AbstractHTTPDestination$WrappedOutputStream
> All of this to say that when the chain's interceptors are working with the message's XMLStreamWriter<http://java.sun.com/javase/6/docs/api/javax/xml/stream/XMLStreamWriter.html>, the bytes are cached and written to the wire. It is not possible to catch the fault XML message and change it.
> The only thing I've come up with but not implemented yet would be to insert an interceptor before the XML declaration is written and put the XMLStreamWriter<http://java.sun.com/javase/6/docs/api/javax/xml/stream/XMLStreamWriter.html> into a temp spot in the message content map, then put a new XMLStreamWriter<http://java.sun.com/javase/6/docs/api/javax/xml/stream/XMLStreamWriter.html> on a byte array in its place. A pre-stream-ending interceptor can take those bytes, apply XSL to them and then write them to the original XMLStreamWriter<http://java.sun.com/javase/6/docs/api/javax/xml/stream/XMLStreamWriter.html>, before putting the original XMLStreamWriter<http://java.sun.com/javase/6/docs/api/javax/xml/stream/XMLStreamWriter.html> back in it original slot in the message content map.
> That seems like big old hack.
> Any ideas on a cleaner solution?
> Thank you,
> Gary Gregory
> Seagull Software
> ggregory@seagullsoftware.com
> www.seagullsoftware.com

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