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 

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 

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.


Reply via email to