Hi Sergey, 2013/1/14 Sergey Beryozkin <[email protected]>: > 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 :-)
:-) 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<[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 > > >
