[
https://issues.apache.org/jira/browse/CXF-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794754#action_12794754
]
Gary Gregory commented on CXF-2594:
-----------------------------------
-----Original Message-----
From: Daniel Kulp [mailto:[email protected]]
Sent: Tuesday, December 22, 2009 19:51
To: [email protected]
Cc: Gary Gregory
Subject: Re: Inflexible fault interceptor chain?
On Tue December 22 2009 4:30:30 pm Gary Gregory wrote:
> Hi All:
>
> I am trying to build SVN 2.2.x (I just updated from SVN) to test a patch (I
> do not have a test yet) just to see what happens if SAAJOutInterceptor
> uses a W3CDOMStreamWriter even if the local variable is null. Since that
> caused a test to hang I thought I'd try to build an unchanged 2.2.6 as a
> baseline. I get the errors below when I run:
>
> mvn clean install -Peverything
>
> Does 2.2.x build ok for anyone out there?
The automatic builds we have running in Hudson seem to be fine:
http://hudson.zones.apache.org/hudson/view/CXF/
They also just worked for me. Not sure what to suggest. :-(
Dan
> 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
>
>
> 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.phaseinterceptorch...@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.isolatin1xmlwri...@1125cf44<mailto:com.ctc.wstx.sw.isolatin1xmlwri...@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
> [email protected]
> www.seagullsoftware.com
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
