cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CXF-2594) No SOAP fault XML elements when a Fault is thrown in the output chain after SAAJOutInterceptor
Date Mon, 28 Dec 2009 00:12:29 GMT

     [ https://issues.apache.org/jira/browse/CXF-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gary Gregory updated CXF-2594:
------------------------------

    Attachment: patch.txt

The patch contains:

- 1 unit test class
- 1 servlet mimicking our runtime code
- 1 input test fixture
- 1 output test fixture

The @Test method {{testSAAJOutInterceptorBroken}} fails and demonstrates the bug.

The @Test method {{testSAAJOutInterceptorIncompleteHackBreaksOtherTests}} passes and shows
a workaround hack that works in this instance but breaks tests in the CXF build.


> 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
>         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
>             Fix For: 2.2.6
>
>         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<mailto:com.ctc.wstx.sw.ISOLatin1XmlWriter@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.


Mime
View raw message