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+s465427n5820565...@n5.nabble.com] Sent: Wednesday, June 13, 2018 5:59 AM To: Bagwell, Allen F <afba...@sandia.gov> 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>
