camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafal Janik <>
Subject Re: Ambiguous method invocations in bean binding
Date Thu, 04 Nov 2010 08:09:51 GMT

thanks a lot for all answers!

Sorry Christian, I forgot about it:

camel-core (2.2.0)
activemq-camel (5.3.0)



> On Thu, Nov 4, 2010 at 12:28 AM, Christian Müller
> <>  wrote:
>> Hello Rafal!
>> Please provide more details like the Camel version you are using in further
>> questions. Please have a look here:
>> However, I assume you have a String as payload in your message. The default
>> Camel type converter mechanism is able to convert this payload also into an
>> InputStream. This is the reason, why this is ambiguous for Camel...
>> I wondering, if we SHOULD make Camel a bit smarter here. I made a patch
>> which fixes this issue. We check whether the message payload is an instance
>> of the bean method argument. If so, we will use this method and don't
>> convert the body. Any objections?
> Camel already has this logic. Its just that the payload most likely
> isn't neither an InputStream type or a String type.
> And the payload is both convertable to InputStream and String. Hence
> Camel don't know which type your prefer.
> What we should maybe allow is to end user to specify that
> .to("bean:foo?method=methodA&")
> Or like
> .to("bean:foo?method=methodA(")
>> Cheers,
>> Christian

Software Mind 	

*Rafal Janik*
Software Engineer
*Software Mind S.A.*
ul. Bociana 22A
31-231 Krakow

	Tel. +48 12 252 34 00
Fax: +48 12 252 34 01
Mobile:+48 668 483 613 <> <>

This email may contain confidential and privileged material for the sole 
use of the intended recipient(s). Any review, use, retention, 
distribution or disclosure by others is strictly prohibited. If you are 
not the intended recipient (or authorized to receive for the recipient), 
please contact the sender by reply email and delete all copies of this 
message. Also, email is susceptible to data corruption, interception, 
tampering, unauthorized amendment and viruses. We only send and receive 
emails on the basis that we are not liable for any such corruption, 
interception, tampering, amendment or viruses or any consequence thereof.

View raw message