Hi Aki
On 2013-01-14 16:04, Aki Yoshida wrote:
Hi Oliver,
Technically, you could write an interceptor that extends the
TransformOutInterceptor and in its handleMessage method, remove the
exception from the message, call super.handleMethod and reinsert the
exception. And let the standard soap fault interceptor serialize the
fault/exception over the transform out filter. I think this would
work.
Of course, that I could do anyways. Reason why I was asking was because
I was wondering if there is a standard way to cover my needs without
subclassing the interceptor. But I guess this is the way to go :-)
But I think it could probably make more sense to even skip this check
in TransformOutInterceptor's handle method or at least to provide an
option to skip this check in there so that you don't need that kind
of
construction.
I agree. However, I do not understand why this check is needed anyways,
resp. why the interceptor makes this distinction between regular
messages and faults. Thing is you need to know what you are doing
anyways, since you have to explicitly configure it in the
outFaultInterceptor chain.
cheers
regards, aki
2013/1/14 Oliver Moser <[email protected]>:
Hi all
I'm trying to transform a namespace in a SoapFault. At first glance,
the
StaxTransformFeature or the TransformOutInterceptor (which can be
configured
in the <outFaultInterceptors> list) looked promising. After playing
around a
bit, I realized that the TransformOutInterceptor might not be
intended to
transform the content of a SoapFault. In my understanding, the
handleMessage() method prohibits this by the following line
//
org.apache.cxf.interceptor.transform.TransformOutInterceptor#handleFault
if (null != message.getContent(Exception.class)) {
return;
}
Is there an alternative approach that allows to transform namespaces
in
SoapFault messages?
cheers
--
Oliver Moser
http://www.omoser.com
--
Oliver Moser
