cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: TransformOutInterceptor and SoapFaults
Date Mon, 14 Jan 2013 16:41:17 GMT
Hi Aki,

On 14/01/13 16:22, Aki Yoshida wrote:
> 2013/1/14 Oliver Moser<>:
>> 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.
> I am also not sure about the usefulness of this check in the current
> setup. In any case, it is strange if the interceptor is inserted into
> the fault chain but omits doing its work if there is an exception set
> in the message. So there seems to be some mismatch in its purpose and
> use.
> This TransformOut interceptor is used in various scenarios including
> REST etc, in some of those cases, it might make sense to skip the
> transformation if an exception is set in the message.

This check was added with :-)

> If this check is skipped, the transform feature will probably need to
> provide an option to insert a separately configured interceptor for
> the fault case so that the normal configuration and the fault
> configuration can be separately configured.
> @Sergey
> what do you think?

Can we keep this check given TransformOutInterceptor is kind of meant to 
be used on the normal out path and add TransformOutFaultInterceptor 
instead to be added explicitly when really needed, with both 
interceptors sharing most of the base code ?
Or lets add a boolean flag to TransformOutInterceptor which will 
optionally let use TransformOutInterceptor be used on the fault chain
too, which is what you suggested too

Thanks, Sergey

> regards, aki
>> cheers
>>> regards, aki
>>> 2013/1/14 Oliver Moser<>:
>>>> 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
>> --
>> Oliver Moser

View raw message