Type converter misbehavior with camel-cxf and camel-mail

["Bagwell, Allen F" <af...@sandia.gov.INVALID>]

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

Re: Type converter misbehavior with camel-cxf and camel-mail

[Quinn Stevenson <qu...@pronoia-solutions.com>]

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 <wi...@gmail.com> 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 <
> afbagwe@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
>> 

Re: Type converter misbehavior with camel-cxf and camel-mail

[Willem Jiang <wi...@gmail.com>]

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 <
afbagwe@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
>

Re: Type converter misbehavior with camel-cxf and camel-mail

[Claus Ibsen <cl...@gmail.com>]

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
<af...@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