Re: Type converter misbehavior with camel-cxf and camel-mail
I would have never known I needed a String -> Object converter for the body unless I stepped through the CfxRsProducer code with a debugger. Therefore I’m not sure that handing some kind of control/override mechanism to the developer via a configuration would not have helped me.
Fundamentally, this seems to be an issue where the camel component in question needs to be able to prioritize its own type converters first. Camel-cxf has the classes in the package: org.apache.camel.component.cxf.converter
and camel-mail has the class org.apache.camel.component.mail.MailConverters
Is there any way to tell the Type Converter search code to prioritize a component’s own converters first?
From: Willem.Jiang [via Camel] [mailto:ml+s465427n5820564h86@xxxxxxxxxxxxx]
Sent: Wednesday, June 13, 2018 2:30 AM
To: Bagwell, Allen F <afbagwe@xxxxxxxxxx>
Subject: [EXTERNAL] Re: Type converter misbehavior with camel-cxf and camel-mail
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
On Wed, Jun 13, 2018 at 3:25 AM, Bagwell, Allen F <
[hidden email]</user/SendEmail.jtp?type=node&node=5820564&i=0>> 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.
If you reply to this email, your message will be added to the discussion below:
To unsubscribe from Camel - Users, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=465428&code=YWZiYWd3ZUBzYW5kaWEuZ292fDQ2NTQyOHwtNDQyMTA1NTgz>.