Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: native english readability enhancements

Bean Binding

The Bean Binding in Camel defines both which methods are invoked and also how the Message is converted into the parameters of the method when it is invoked.

...

The binding of a Camel Message to a bean method call can occur in different ways, in the following order if of importance:

  • if the message contains the header CamelBeanMethodName then that method is invoked, converting the body to whatever the argument is to type of the method's argument.
    • From Camel 2.8 onwards you can qualify parameter types to exact pin-point select exactly which method to use when using overloaded methods among overloads 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).
  • you can explicitly specify 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 the @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 The ActiveMQ component uses this mechanism 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) component - then that its is used to invoke the method and pass the its arguments
  • otherwise the type of the method body is used to try find a matching 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 cases where Camel will not be able to cannot choose a method to invoke, an AmbiguousMethodCallException is thrown.

...

Parameter binding

When a method have has been chosen to be invoked for invokation, Camel will bind to the parameters of the method.

The following Camel-specific types is automatic bindedare automatically bound:

  • org.apache.camel.Exchange
  • org.apache.camel.Message
  • org.apache.camel.CamelContext
  • org.apache.camel.TypeConverter
  • org.apache.camel.spi.Registry
  • java.lang.Exception

So, if you declare any of the given type above these types, they will be provided by Camel. A note on the Exception is that it Note that Exception will bind to the caught exception of the Exchange. So its - so it's often usable if you use employ a POJO to handle a given using using eg , e.g., an onException route.

What is most interesting is that Camel will also try to bind the body of the Exchange to the first parameter of the method signature (albeit not of any of the types above). So if we , for instance, we declare e a parameter as : String body, then Camel will bind the IN body to this type. Camel will also automatic type automatically convert to the given type declared in the method signature.

Okay lets show Let's review some examples.:

Below is just a simple method with a body binding. Camel will bind the IN body to the body parameter and convert it to a String type.

Code Block
public String doSomething(String body)

And in this In the following sample we got one of the automatic binded type automatically-bound types as well , - for instance the , a Registry that we can use to lookup beans.

Code Block
public String doSomething(String body, Registry registry)

And we We can also use Exchange as well:

Code Block
public String doSomething(String body, Exchange exchange)

You can also have multiple types as well:

Code Block
public String doSomething(String body, Exchange exchange, TypeConverter converter)

And imagine you use a POJO to handle a given custom exception InvalidOrderException then - we can then bind that as well:

Code Block

public String badOrder(String body, InvalidOrderException invalid)

Notice that we can bind to it even if we use a sub type of java.lang.Exception as Camel still knows its it's an exception and thus can bind the caused exception cause (if any exists).

...

So what about headers and other stuff? Well now it gets a bit tricky - so we can use annotations to help us, or specify the binding in the method name option.
See the following sections for more detailsdetail.

Binding Annotations

You can use the Parameter Binding Annotations to customize how parameter values are created from the Message

Examples

For example, a Bean such as:

Code Block
public class Bar {

    public String doSomething(String body) {
      // process the in body and return whatever you want
      return "Bye World";
   }

...

You can mark a method in your bean with the @Handler annotation to indicate that this method should be used for Bean Binding.
This has the an advantage as you do need not have to specify the a method name in the Camel route. And thus you , and therefore do not run into problems when you rename after renaming the method name using in an IDE that doncan't find all its references.

Code Block
java
java
public class Bar {

    @Handler
    public String doSomething(String body) {
      // process the in body and return whatever you want
      return "Bye World";
   }

...

Camel uses the following rules to determine if its it's a parameter value in the method option

  • The value is either true or false which denotes a boolean value
  • The value is a numeric value such as 123 or 7
  • The value is a String enclosed with either single or double quotes
  • The value is null which denotes a null value
  • It can be evaluated using the Simple language, which means you can use eg , e.g., body, header.foo and other Simple tokens. Notice the tokens must be enclosed with ${ }.

Any other value is consider to be a type declaration instead , - see the next section about pin pointing specifying types for overloaded methods.

When invoking a Bean you can instruct Camel to invoke a specific method by providing the method name. For example as shown below:

Code Block
   .bean(OrderService.class, "doSomething")

Here we tell Camel to invoke the doSomething method . How - Camel handles the parameters is bound is handled by Camel' binding. Now suppose the method has 2 parameters, and the 2nd parameter is a boolean , where we want to pass in a true value, such as the method signature below:

Code Block
public void doSomething(String payload, boolean highPriority) {
   ...
}

...

In the example above, we defined the first parameter using the wild card symbol *, which tells Camel to bind this parameter to any type, and let Camel figure this out. The 2nd parameter has a fixed value of true. Instead of the wild card wildcard symbol we can instruct Camel to use the message body as shown:

...

Code Block
   .to("bean:orderService?method=doSomething(null, true)")

By specifying Specifying null as a parameter value , it instructs Camel to force passing in a null value.

Besides the message body, you can pass in the message headers as a java.util.Map type, and declare it as follows:

Code Block
   .bean(OrderService.class, "doSomethingWithHeaders(${body}, ${headers})")

You can also pass in other fixed values than boolean valuesbesides booleans. For example to , you can pass in an a String and an integer do as follows:

Code Block
   .bean(MyBean.class, "echo('World', 5)")

In the example above, we invoke the echo method with two parameters. The first has the content 'World' (without the quotes). And , and the 2nd has the value of 5.
Camel will automatic type automatically convert the these values to the parameter parameters' types.

Having the power of the Simple language allows us to bind to message headers and other values such as:

...

Code Block
   .to("bean:orderService?method=doSomething(${body.asXml}, ${header.high})")

Using type

...

qualifiers to select among overloaded methods

Available as of Camel 2.8

If you have a Bean which has with overloaded methods, you can now specify the parameter types in the method name , so Camel can match the method you intend to use.
Given the following bean:

...

By default Camel will match the type name using the simple name, eg e.g. any leading package name will be disregarded. However if you want to match using the FQN, then specify the FQN type and Camel will leverage that. So if you have a com.foo.MyOrder and you want to match against the FQN, and not the simple name "MyOrder" then do as follows, then follow this example:

Code Block
   .bean(OrderService.class, "doSomething(com.foo.MyOrder)")

...