[jira] [Comment Edited] (CAMEL-19160) add Object to String converter method to camel-jaxb

["Freeman Yue Fang (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-19160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701956#comment-17701956 ] 

Freeman Yue Fang edited comment on CAMEL-19160 at 3/17/23 7:18 PM:
-------------------------------------------------------------------

Hi [~davsclaus],

Thanks for the feedback!

More background of this issue,  [~jondruse] drew me attention through this [PR|https://github.com/apache/camel-quarkus/pull/4653] on Camel Quarkus.

We found that if we put code like
{code}
                    GetPersonResponse reply = new GetPersonResponse();
                    reply.setPersonId(request.getPersonId() + "2");
                    exchange.getMessage().setBody(reply);
{code}
and we expect convert mechanism can kick in and change type from GetPersonResponse to org.apache.camel.component.cxf.common.CxfPayload. This test fails randomly. After debugging, I found that we have two fallback converter on the classpath, one is org.apache.camel.converter.jaxb.FallbackTypeConverter.convertTo from camel-jaxb, another one is org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo from camel-cxf, but which one will be used first is uncertain. So for the expected "GetPersonResponse to org.apache.camel.component.cxf.common.CxfPayload" convert, if the fallback converter from org.apache.camel.converter.jaxb.FallbackTypeConverter.convertTo is used, the test passes, otherwise(the fallback converter from camel-cxf is used) it fails.

The interesting thing is this uncertainty only happens  in CEQ runtime, I've never seen this behaviour in CSB/OSGi/standalone.

My original fix was about to add an Object===>String converter in camel-jaxb so that I can leverage jaxb marshaller there and I can call it from camel-cxf converter if necessary. I understand that this is too general and risky. How about if I add Object===>Document/Element converter in camel-jaxb instead, is it OK? Or in camel, do we have mechanism to order fallback converter if there were many on the classpath? I know we can order normal converters from the same bulkloader but seems we can't order fallback converters. What your suggestions to resolve this issue?

Thanks!
Freeman



was (Author: ffang):
Hi [~davsclaus],

Thanks for the feedback!

More background of this issue,  [~jondruse] drew me attention through this [PR|https://github.com/apache/camel-quarkus/pull/4653] on Camel Quarkus.

We found that if we put code like
{code}
                    GetPersonResponse reply = new GetPersonResponse();
                    reply.setPersonId(request.getPersonId() + "2");
                    exchange.getMessage().setBody(reply);
{code}
and we expect convert mechanism can kick in and change type from GetPersonResponse to org.apache.camel.component.cxf.common.CxfPayload. This test fails randomly. After debugging, I found that we have two fallback converter on the classpath, one is org.apache.camel.converter.jaxb.FallbackTypeConverter.convertTo from camel-jaxb, another one is org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo from camel-cxf, but which one will be used first is uncertain. So for the expected "GetPersonResponse to org.apache.camel.component.cxf.common.CxfPayload" convert, if the fallback converter from org.apache.camel.converter.jaxb.FallbackTypeConverter.convertTo is used, the test passes, otherwise(the fallback converter from camel-cxf is used) it fails.

The interesting thing is this uncertainty only happens  in CEQ runtime, I've never seen this behaviour in CSB/OSGi/standalone.

My original fix was about to add an Object-->String converter in camel-jaxb so that I can leverage jaxb marshaller there and I can call it from camel-cxf converter if necessary. I understand that this is too general and risky. How about if I add Object-->Document/Element converter in camel-jaxb instead, is it OK? Or in camel, do we have mechanism to order fallback converter if there were many on the classpath? I know we can order normal converters from the same bulkloader but seems we can't order fallback converters. What your suggestions to resolve this issue?

Thanks!
Freeman


> add Object to String converter method to camel-jaxb
> ---------------------------------------------------
>
>                 Key: CAMEL-19160
>                 URL: https://issues.apache.org/jira/browse/CAMEL-19160
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-jaxb
>            Reporter: Freeman Yue Fang
>            Assignee: Freeman Yue Fang
>            Priority: Major
>
> So we get the change to return xml fragment(jaxb marshaller) from the object if necessary.
> registry.lookup(String.class, Object.class) can return the jaxb converter if camel-jaxb is on the classpath



--
This message was sent by Atlassian Jira
(v8.20.10#820010)