You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Oliver Moser <o...@omoser.com> on 2013/01/14 12:36:23 UTC
TransformOutInterceptor and SoapFaults
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
Re: TransformOutInterceptor and SoapFaults
Posted by Oliver Moser <o...@omoser.com>.
here's the JIRA
https://issues.apache.org/jira/browse/CXF-4752
cheers
On 01/14/2013 06:16 PM, Sergey Beryozkin wrote:
> Hi Aki - lol :-), I forget too sometimes that it was me who added some
> code; I guess though this check is OK to be on by default so your fix
> was perfect :-)
>
> Cheers, Sergey
> On 14/01/13 17:12, Aki Yoshida wrote:
>> Hi Sergey,
>>
>> 2013/1/14 Sergey Beryozkin<sb...@gmail.com>:
>>> Hi Aki,
>>>
>>>
>>> On 14/01/13 16:22, Aki Yoshida wrote:
>>>>
>>>> 2013/1/14 Oliver Moser<o...@omoser.com>:
>>>>>
>>>>> 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 :-)
>>
>> :-) Funny. I am embarrassed. I should have checked it by myself. I
>> didn't remember that.
>>
>>>
>>>
>>>>
>>>> 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
>>
>> Okay. Something like that.
>>
>> @Oliver,
>> If you could create a jira ticket and link this mail thread, that
>> would be appreciated.
>>
>> thanks.
>>
>> regards, aki
>>
>>>
>>> Thanks, Sergey
>>>
>>>
>>>>
>>>> regards, aki
>>>>
>>>>>
>>>>> cheers
>>>>>
>>>>>
>>>>>>
>>>>>> regards, aki
>>>>>>
>>>>>> 2013/1/14 Oliver Moser<o...@omoser.com>:
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>
>>>
>>>
>
--
Oliver Moser
Re: TransformOutInterceptor and SoapFaults
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Aki - lol :-), I forget too sometimes that it was me who added some
code; I guess though this check is OK to be on by default so your fix
was perfect :-)
Cheers, Sergey
On 14/01/13 17:12, Aki Yoshida wrote:
> Hi Sergey,
>
> 2013/1/14 Sergey Beryozkin<sb...@gmail.com>:
>> Hi Aki,
>>
>>
>> On 14/01/13 16:22, Aki Yoshida wrote:
>>>
>>> 2013/1/14 Oliver Moser<o...@omoser.com>:
>>>>
>>>> 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 :-)
>
> :-) Funny. I am embarrassed. I should have checked it by myself. I
> didn't remember that.
>
>>
>>
>>>
>>> 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
>
> Okay. Something like that.
>
> @Oliver,
> If you could create a jira ticket and link this mail thread, that
> would be appreciated.
>
> thanks.
>
> regards, aki
>
>>
>> Thanks, Sergey
>>
>>
>>>
>>> regards, aki
>>>
>>>>
>>>> cheers
>>>>
>>>>
>>>>>
>>>>> regards, aki
>>>>>
>>>>> 2013/1/14 Oliver Moser<o...@omoser.com>:
>>>>>>
>>>>>>
>>>>>> 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
>>
>>
>>
Re: TransformOutInterceptor and SoapFaults
Posted by Aki Yoshida <el...@gmail.com>.
Hi Sergey,
2013/1/14 Sergey Beryozkin <sb...@gmail.com>:
> Hi Aki,
>
>
> On 14/01/13 16:22, Aki Yoshida wrote:
>>
>> 2013/1/14 Oliver Moser<o...@omoser.com>:
>>>
>>> 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 :-)
:-) Funny. I am embarrassed. I should have checked it by myself. I
didn't remember that.
>
>
>>
>> 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
Okay. Something like that.
@Oliver,
If you could create a jira ticket and link this mail thread, that
would be appreciated.
thanks.
regards, aki
>
> Thanks, Sergey
>
>
>>
>> regards, aki
>>
>>>
>>> cheers
>>>
>>>
>>>>
>>>> regards, aki
>>>>
>>>> 2013/1/14 Oliver Moser<o...@omoser.com>:
>>>>>
>>>>>
>>>>> 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
>
>
>
Re: TransformOutInterceptor and SoapFaults
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Aki,
On 14/01/13 16:22, Aki Yoshida wrote:
> 2013/1/14 Oliver Moser<o...@omoser.com>:
>> 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<o...@omoser.com>:
>>>>
>>>> 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
Re: TransformOutInterceptor and SoapFaults
Posted by Aki Yoshida <el...@gmail.com>.
2013/1/14 Oliver Moser <o...@omoser.com>:
> 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.
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?
regards, aki
>
> cheers
>
>
>>
>> regards, aki
>>
>> 2013/1/14 Oliver Moser <o...@omoser.com>:
>>>
>>> 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
RE: TransformOutInterceptor and SoapFaults
Posted by Oliver Moser <o...@omoser.com>.
Hi Andrei
On 2013-01-15 09:49, Andrei Shakirin wrote:
> Hi Oliver,
>
> As alternative you can try "heavy" version of
> StaxTransformationFeature: XLSTFeature (XSLTOutInterceptor).
> It requires to configure xslt script for transformation and has some
> performance penalty because of broken streaming, but anyway can suit
> your purposes.
> The XSLTOutInterceptor should be added after FaultOutInterceptor in
> chain.
Thanks for the hint, for the time being I subclassed
TransformOutInterceptor, works perfect.
>
> +1 to introduce flag in TransformOutInterceptor to allow fault
> processing.
Actually I would vote for an explicit TransformOutFaultInterceptor, but
that's for Aki to decide.
cheers
Oliver
>
>> -----Original Message-----
>> From: Oliver Moser [mailto:o@omoser.com]
>> Sent: Montag, 14. Januar 2013 16:11
>> To: users@cxf.apache.org
>> Subject: Re: TransformOutInterceptor and SoapFaults
>>
>> 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 <o...@omoser.com>:
>> >> 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
--
Oliver Moser
RE: TransformOutInterceptor and SoapFaults
Posted by Andrei Shakirin <as...@talend.com>.
Hi Oliver,
As alternative you can try "heavy" version of StaxTransformationFeature: XLSTFeature (XSLTOutInterceptor).
It requires to configure xslt script for transformation and has some performance penalty because of broken streaming, but anyway can suit your purposes.
The XSLTOutInterceptor should be added after FaultOutInterceptor in chain.
+1 to introduce flag in TransformOutInterceptor to allow fault processing.
Cheers,
Andrei.
> -----Original Message-----
> From: Oliver Moser [mailto:o@omoser.com]
> Sent: Montag, 14. Januar 2013 16:11
> To: users@cxf.apache.org
> Subject: Re: TransformOutInterceptor and SoapFaults
>
> 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 <o...@omoser.com>:
> >> 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
Re: TransformOutInterceptor and SoapFaults
Posted by Oliver Moser <o...@omoser.com>.
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 <o...@omoser.com>:
>> 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
Re: TransformOutInterceptor and SoapFaults
Posted by Aki Yoshida <el...@gmail.com>.
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.
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.
regards, aki
2013/1/14 Oliver Moser <o...@omoser.com>:
> 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
>