Type converter misbehavior with camel-cxf and camel-mail
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.