Camel uses the traditional Java SPI loading mechanism. camel-core just loads the type converters by looking up the type convert file from the class path. It cannot tell which one is prioritized unless we add an order number into the converter, but the number cannot be changed by user.
Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Fri, Jun 15, 2018 at 12:25 AM, Bagwell, Allen F < afba...@sandia.gov.invalid> wrote: > I would have never known I needed a String -> Object[] converter for the > body unless I stepped through the CfxRsProducer code with a debugger. > Therefore I’m not sure that handing some kind of control/override mechanism > to the developer via a configuration would not have helped me. > > Fundamentally, this seems to be an issue where the camel component in > question needs to be able to prioritize its own type converters first. > Camel-cxf has the classes in the package: org.apache.camel.component. > cxf.converter > > and camel-mail has the class org.apache.camel.component. > mail.MailConverters > > Is there any way to tell the Type Converter search code to prioritize a > component’s own converters first? > > -Allen > > From: Willem.Jiang [via Camel] [mailto:ml+s465427n5820564...@n5.nabble.com > ] > Sent: Wednesday, June 13, 2018 2:30 AM > To: Bagwell, Allen F <afba...@sandia.gov> > Subject: [EXTERNAL] Re: Type converter misbehavior with camel-cxf and > camel-mail > > 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=5820564&i=0>> 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-tp5820546p5820564.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> >
