osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Type converter misbehavior with camel-cxf and camel-mail


In my preparation step, I was doing this as the last bit in my processor prior to invoking the client:

inMessage.setBody(status, String.class);

I also tried inserting an explicit conversion into the blueprint right before the client invocation:

<convertBodyTo class=”java.lang.String”/>

Neither approach worked. I still got the CxfRsProducer throwing a NoSuchMethodException.

-Allen


From: Quinn Stevenson [via Camel] [mailto:ml+s465427n5820565h17@xxxxxxxxxxxxx]
Sent: Wednesday, June 13, 2018 5:59 AM
To: Bagwell, Allen F <afbagwe@xxxxxxxxxx>
Subject: [EXTERNAL] Re: Type converter misbehavior with camel-cxf and camel-mail

Not sure if this is an option, but can you insert a call to a bean (or processor) before the CXF call that does the body conversion the way you want?

> On Jun 13, 2018, at 3:30 AM, Willem Jiang <[hidden email]</user/SendEmail.jtp?type=node&node=5820565&i=0>> wrote:
>
> Hi Bagwell,
>
> Thank you for share your experience of using the camel type converter.
>
> Most time the embedded type converter just work as it is designed, but we
> cannot guarantee it works in different combinations.
> as we don't provide the override mechanism which could introduce some
> trouble for user to resolve the type convert conflict.
> Maybe we could introduce some option in the application context to give
> user a chance to get back control of which converter can work.
>
> The first thing came into my mind is configuration file which ship with the
> application to decide the order of the type converter.
> But I'm not sure if it can work across all the deployment that camel
> supports.
>
> any thought?
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Jun 13, 2018 at 3:25 AM, Bagwell, Allen F <
> [hidden email]</user/SendEmail.jtp?type=node&node=5820565&i=1>> wrote:
>
>> I'm trying to integrate a CXF REST client into my camel route that already
>> has a SMTP endpoint incorporated into it via camel-mail. (This is using
>> Camel 2.18.5)
>>
>> When the client is invoked (this is configured via a blueprint), the
>> CxfRsProducer class in camel-cxf has the resource class loaded that I have
>> defined and using the proxy (CxfConstants.CAMEL_CXF_RS_USING_HTTP_API =
>> false, CxfConstants.OPERATION_NAME = "putStatus") it successfully looks up
>> the method the client needs, which in this case will use the String body of
>> the in-message to set as a parameter.
>>
>> This is where it gets weird. The CxfRsProducer needs to find a converter
>> to take the String body and turn it into an Object[]. In every other case
>> where I've done this, it finds the appropriate type converter and life is
>> good.  However when camel-mail is present in the classpath the converter
>> search method picks:
>>
>> com.sun.mail.imap.SortTerm[] org.apache.camel.component.
>> mail.MailConverters.toSortTerm(String msg)
>>
>> This converter fails to produce the desired result and then a list of
>> fallback converters are tried. None of these work either and so the final
>> decision is to not use the in-message body but rather the in-message object
>> itself (DefaultMessage).  This of course isn't the correct solution, so the
>> whole CxfRsProducer bombs on a NoSuchMethodException because it can't find
>> the correct type parameter (String) that my resource class method needs.
>>
>> If I remove camel-mail, the CXF client works exactly as expected because
>> it finds the right String -> Object[] converter.
>>
>> I have never really had to muck around explicitly with converters before,
>> but is there a way to get these two dependencies to cooperate and pick the
>> correct converter? My current workaround is in my preparation of the
>> exchange just before the rest client is invoked I put the String I need to
>> send into an Object[] and set that as the new in-message body. Seems a bit
>> of a kluge, but it allows me to continue.
>>
>> Thanks!
>> -Allen
>>

________________________________
If you reply to this email, your message will be added to the discussion below:
http://camel.465427.n5.nabble.com/Type-converter-misbehavior-with-camel-cxf-and-camel-mail-tp5820546p5820565.html
To unsubscribe from Camel - Users, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=465428&code=YWZiYWd3ZUBzYW5kaWEuZ292fDQ2NTQyOHwtNDQyMTA1NTgz>.
NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>