cxf-issues mailing list archives

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


Gary Gregory commented on CXF-2594:

-----Original Message-----
From: Daniel Kulp [] 
Sent: Tuesday, December 22, 2009 10:06
Cc: Gary Gregory
Subject: Re: Inflexible fault interceptor chain?

Can you create a small test case and attach to a jira?

This definitely sounds like bug of some sort.   When I redid the Provider 
based services, I noticed that strange code in the StaxOutInterceptor as well 
and tried to remove it.   However, that broke some of the JAX-WS tck tests.   
I don't remember the exact reason.   I think it has something to do with 
faults thrown from the logical or soap handlers on the outgoing chain needed 
some strange and wacky processing.     Don't really remember.   

If we can get your test case, we may be able to get it to work better.   

That said, you could probably write your own interceptor (you seem to be good 
at that :-)  that would run on the fault chain prior to the SAAJOut and have 
it remove the SAAJ model from the message.   You may need to trace through a 
couple other interceptors (like SoapOutInterceptor) to see if other properties 
need to be removed/reset.


> No SOAP fault XML elements when a Fault is thrown in the output chain after SAAJOutInterceptor
> ----------------------------------------------------------------------------------------------
>                 Key: CXF-2594
>                 URL:
>             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:
> 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<>.
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<>
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,
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
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<>
into a temp spot in the message content map, then put a new XMLStreamWriter<>
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<>,
before putting the original XMLStreamWriter<>
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

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

View raw message