camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Question on RemoveClassTypeInterceptor in Camel Cxf's Payload mode
Date Fri, 29 Apr 2011 08:33:04 GMT
I would like to understand the CxfPayload instantiation for the CXF to
Camel direction and the purpose of
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

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

View raw message