Well, this is almost true. By default the following Camel components are installed with the Camel feature:
Bind Spring beans to a message exchange.
Use a data set to send large number of messages to stress test a message flow.
Synchronous call to another endpoint.
Consume and produce files from a specified directory.
A List can be used to test and debug message exchanges.
Log the message exchange with Jakarta Commons Logging.
Use the mock component to test a message flow.
Asynchronous call to another endpoint in the same Camel Context.
Send a message on a specific time interval.
Validates the message payload with XML Schema and JAXP validation.
Asynchronous call to another endpoint in the same JVM.
Transforms the message using a XSLT stylesheet.
In the simple file example we used the Camel file component. As you can see on the Camel website, there are a lot of other Camel components available (http://activemq.apache.org/camel/components.html). So if we would like to use the Camel JMS component in the FUSE ESB we should do an additional installation. But the Camel JMS component is not available by default in the features list. To make other Camel components available in the features list we should add a features URL where the provisioning component can retrieve the additional components. Execute the following command to do this using a URL that matches the version of FUSE ESB that you are using:
When we execute the ‘features list’ command now, a large number of additional Camel components is available to install, including the Camel JMS component. So to enable the Camel JMS component functionality just execute the ‘features install camel-jms’ command. So now let’s look at a bit more complex example using the Camel Java DSL implemented with an OSGi bundle.
Deploying an OSGi bundle
In the first example we showed how to use the Camel Spring XML configuration. But when we want to implement a Camel Java DSL route or use Java beans in the integration logic, we need another deployment mechanism. In FUSE ESB 4 the most obvious choice would be an OSGi bundle utilizing the Spring dynamic modules (Spring DM) framework. Figure 3 shows an example we’ll implement with an OSGi bundle.
Figure 3 Camel example that consumes a JMS message and validates it against an XML Schema definition. There is a standard target queue and an error queue in case of validation errors.
We’ll implement a ValidationRouter class with the Camel Java DSL that consumes a hello message from the camel.jms.in JMS queue. The message exchange will be logged and then it will be validated against the hello.xsd XML Schema definition file. When there are no validation errors, the hello message will be sent to the camel.jms.out queue and in the case of validation errors, the message will be forwarded to the camel.jms.error queue.