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 <[email protected]> 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 < > [email protected]> 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 >>
