You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 37 Next »

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.

Choosing the method to invoke

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

  • if the message contains the header CamelBeanMethodName (org.apache.camel.MethodName in Camel 1.x) 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 syntax (see further below for more details).
  • the method name can be specified explicitly in the DSL or when using POJO Consuming
  • Camel 2.0: 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.

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

By default the return value is set on the outbound message body.

Parameter binding

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

The following Camel specific types is automatic binded:

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

So if you declare any of the given type above they will be provided by Camel. A note on the Exception is that it will bind to the caught exception of the Exchange. So its often usable if you use a POJO to handle a given using using eg an onException route.

What is most interresting 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 declare e parameter as: String body then Camel will bind the IN body to this type. Camel will also automatic type convert to the given type declared.

Okay lets show 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.

public String doSomething(String body)

And in this sample we got one of the automatic binded type as well, for instance the Registry that we can use to lookup beans.

public String doSomething(String body, Registry registry)

And we can also use Exchange as well:

public String doSomething(String body, Exchange exchange)

You can have multiple types as well

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 bind that as well:
Notice we can bind to it even if we use a sub type of java.lang.Exception as Camel still knows its an exception and thus can bind the caused exception (if any exists).

public String badOrder(String body, InvalidOrderException invalid)

So what about headers and other stuff? Well now it gets a bit tricky so we can use annotations to help us. See next section for details.

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:

public class Bar {

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

Or the Exchange example. Notice that the return type must be void when there is only a single parameter:

public class Bar {

    public void doSomething(Exchange exchange) {
      // process the exchange
      exchange.getIn().setBody("Bye World");
   }

@Handler

Available as of Camel 2.0

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 advantage as you do not have to specify the method name in the Camel route. And thus you do not run into problems when you rename the method name using an IDE that don't find all references.

public class Bar {

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

POJO consuming

For example you could use POJO Consuming to write a bean like this

@Consume requires camel-spring

Using the @Consume annotations requires camel-spring that uses the org.apache.camel.spring.CamelBeanPostProcessor to perform the setup for this consumer and the needed bean bindings.

@MessageDriven is @deprecated

The @MessageDriven has been replaced with @Consume in Camel 1.5.0 or newer. Its now marked as @deprecated and will be removed in Camel 2.0.

public class Foo {

    @Consume(uri = "activemq:my.queue")
    public void doSomething(String body) {
		// process the inbound message here
    }

}

Here Camel with subscribe to an ActiveMQ queue, then convert the message payload to a String (so dealing with TextMessage, ObjectMessage and BytesMessage in JMS), then process this method.

Using type qualifier to pin-point method to use when having overloaded methods

Available as of Camel 2.8

If you have a Bean which has 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:

Error formatting macro: snippet: java.lang.NullPointerException

Then the MyBean has 2 overloaded methods with the names hello and times. So if we want to use the method which has 2 parameters we can do as follows in the Camel route:

Error formatting macro: snippet: java.lang.NullPointerException

We can also use a * as wildcard so we can just say we want to execute the method with 2 parameters we do

Error formatting macro: snippet: java.lang.NullPointerException

By default Camel will match the type name using the simple name, eg 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:

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

The current implementation for choosing method using type qualifiers only compares the type names. It does not check any instanceof checks or the likes. The type name must match exactly, as its using a string equals comparison.

Specifying parameter values in method name syntax

Available as of Camel 2.9

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

   .bean(OrderService.class, "doSomething")

Here we tell Camel to invoke the doSomething method. How the parameters is bound is handled by Camel. 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:

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

This is now possible in Camel 2.9 onwards:

   .bean(OrderService.class, "doSomething(*, true)")

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 symbol we can instruct Camel to use the message body as shown:

   .bean(OrderService.class, "doSomething(body, true)")

The syntax of the parameters is using the Simple expression language so we can use ${ } placeholders to make this more expressive:

   .bean(OrderService.class, "doSomething(${body}, true)")

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

   .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 the 2nd the value of 5.
Camel will automatic type convert the values to the parameter types.

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

   .bean(OrderService.class, "doSomething(${body}, ${header.high})")

You can also use the OGNL support of the Simple expression language. Now suppose the message body is an object which has a method named asXml. To invoke the asXml method we can do as follows:

   .bean(OrderService.class, "doSomething(${body.asXml}, ${header.high})")

Instead of using .bean as shown in the examples above, you may want to use .to instead as shown:

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