Hi Aki,
On 14/01/13 16:22, Aki Yoshida wrote:
2013/1/14 Oliver Moser<[email protected]>:
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
http://svn.apache.org/viewvc?view=revision&revision=1158144 :-)
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<[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
