Question on RemoveClassTypeInterceptor in Camel Cxf's Payload mode

[Aki Yoshida <el...@googlemail.com>]

I would like to understand the CxfPayload instantiation for the CXF to
Camel direction and the purpose of
org.apache.camel.component.cxf.interceptors.RemoveClassTypeInterceptor
that gets inserted into the CXF interceptor chain by Camel under the
payload mode. I think there is potentially some case in which some
change is required.

As I see, this interceptor removes the type information from the
MessagePartInfo object to affect how the payload object is
instantiated later, more concretely to enforce the use of DOM that is
used in Camel's CxfPayload. This interceptor is inserted after the
DocLiteralInInterceptor, which is instantiating the payload object in
some form. So for the very first call, it may not necessarily enforce
this condition (e.g., when the type is the plain
javax.xml.transform.Source, the StaxSource object gets instantiated
instead). And this currently leads to a payload transfer error. For
the subsequent calls, the DOM based object gets instantiated as the
type information is removed in the first call and the payloads get
correctly transferred.

Initially, I thought I could just move RemoveClassTypeInterceptor in
front of DocLiteralInInterceptor so that the type information is
removed before the first instantiation takes place. But I noticed that
this doesn't work because RemoveClassTypeInterceptor needs the binding
operation information which is set by DocLiteralInInterceptor in the
exchange context.

So, to solve this situation, it seems that we need to modify
CxfDefaultBinding to accept the Source in its getPayloadBodyElements
method so that the DOM based payload gets created from a non-DOMSource
based Source like StaxSource.

With this change, I could see the payload gets correctly transferred
from CXF to Camel also for the first call.

As this problem only occurs when you have the Source based service
method (e.g., one extending Provider<Source>), I am not sure if this
issue is already known or unknown. Or I may be missing something
totally.

Could someone comment on this? If my description is not clear, I can
provide a simple test case to illustrate this issue.

Thanks for your advice.
Regards, Aki

Re: Question on RemoveClassTypeInterceptor in Camel Cxf's Payload mode

[Aki Yoshida <el...@googlemail.com>]

Hi,
I noticed that CxfConsumerProviderTest did something similar to what I
am doing, but it strangely did not encounter this issue. Then, I
noticed that this test case was implicitly using the POJO mode and not
the PAYLOAD mode.

When I added the dataFormat parameter in the endpoint URL (i.e.,
adding dataFormat=PAYLOAD), the control went into the payload
extraction code for the PAYLOAD mode that I was talking about and this
resulted in the described payload extraction issue.

I suppose this test case should be using the PAYLOAD mode, no? In that
case, we should add the dataFormat=PAYLOAD in the endpoint URL.

If no one says otherwise, I can create a jira ticket and attach this
change and the suggested patch in CxfDefaultBinding to fix this issue.

Regards, Aki

2011/4/29 Aki Yoshida <el...@googlemail.com>:
> I would like to understand the CxfPayload instantiation for the CXF to
> Camel direction and the purpose of
> org.apache.camel.component.cxf.interceptors.RemoveClassTypeInterceptor
> that gets inserted into the CXF interceptor chain by Camel under the
> payload mode. I think there is potentially some case in which some
> change is required.
>
> As I see, this interceptor removes the type information from the
> MessagePartInfo object to affect how the payload object is
> instantiated later, more concretely to enforce the use of DOM that is
> used in Camel's CxfPayload. This interceptor is inserted after the
> DocLiteralInInterceptor, which is instantiating the payload object in
> some form. So for the very first call, it may not necessarily enforce
> this condition (e.g., when the type is the plain
> javax.xml.transform.Source, the StaxSource object gets instantiated
> instead). And this currently leads to a payload transfer error. For
> the subsequent calls, the DOM based object gets instantiated as the
> type information is removed in the first call and the payloads get
> correctly transferred.
>
> Initially, I thought I could just move RemoveClassTypeInterceptor in
> front of DocLiteralInInterceptor so that the type information is
> removed before the first instantiation takes place. But I noticed that
> this doesn't work because RemoveClassTypeInterceptor needs the binding
> operation information which is set by DocLiteralInInterceptor in the
> exchange context.
>
> So, to solve this situation, it seems that we need to modify
> CxfDefaultBinding to accept the Source in its getPayloadBodyElements
> method so that the DOM based payload gets created from a non-DOMSource
> based Source like StaxSource.
>
> With this change, I could see the payload gets correctly transferred
> from CXF to Camel also for the first call.
>
> As this problem only occurs when you have the Source based service
> method (e.g., one extending Provider<Source>), I am not sure if this
> issue is already known or unknown. Or I may be missing something
> totally.
>
> Could someone comment on this? If my description is not clear, I can
> provide a simple test case to illustrate this issue.
>
> Thanks for your advice.
> Regards, Aki
>