Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • if the message contains the header CamelBeanMethodName then that method is invoked, converting the body to whatever the argument is to the method.
    • From Camel 2.8 onwards you can qualify parameter types to exact pin-point which method to use when using overloaded methods with the same name (see further below for more details).
    • From Camel 2.9 onwards you can specify parameter values directly in the method option (see further below for more details).
  • the method name can be specified explicitly in the DSL or when using POJO Consuming or POJO Producing
  • if the bean has a method that is marked with @Handler annotation then that method is selected
  • if the bean can be converted to a Processor using the Type Converter mechanism then this is used to process the message. This mechanism is used by the ActiveMQ component to allow any JMS MessageListener to be invoked directly by Camel without having to write any integration glue code. You can use the same mechanism to integrate Camel into any other messaging/remoting frameworks.
  • if the body of the message can be converted to a BeanInvocation (the default payload used by the ProxyHelper) - then that its used to invoke the method and pass the arguments
  • otherwise the type of the method body is used to try find a method which matches; an error is thrown if a single method cannot be chosen unambiguously.
  • you can also use Exchange as the parameter itself, but then the return type must be void.
  • if the bean class is private (or package-private), interface methods will be preferred (from Camel 2.9 onwards) since Camel can't invoke class methods on such beans

In case where Camel will not be able to choose a method to invoke an AmbiguousMethodCallException is thrown.

...