Hi

Ah darn we can try to look into avoiding that type converter in
camel-mail - we can potentially do the conversion manually.
You are welcome to log a JIRA ticket.



On Tue, Jun 12, 2018 at 9:25 PM, Bagwell, Allen F
<afba...@sandia.gov.invalid> 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



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Reply via email to