How do I configure endpoints?

There are a few different approaches to configuring components and endpoints.

Using Java Code

You can explicitly configure a Component using Java code as shown in this example

Or you can explicitly get hold of an Endpoint and configure it using Java code as shown in the Mock endpoint examples.

Using Guice

You can also use Guice as the dependency injection framework. For example see the Guice JMS Example

Using Spring XML

You can configure your Component or Endpoint instances in your Spring XML as follows.

Which allows you to configure a component using some name (activemq in the above example), then you can refer to the component using activemq:[queue:|topic:]destinationName. This works by the SpringCamelContext lazily fetching components from the spring context for the scheme name you use for Endpoint URIs

Using Endpoint URIs

Another approach is to use the URI syntax. The URI syntax supports the query notation. So for example with the Mail component you can configure the password property via the URI

Referring beans from Endpoint URIs

Available as of Camel 2.0

When configuring endpoints using URI syntax you can now refer to beans in the Registry using the # notation.
If the parameter value starts with a # sign then Camel will lookup in the Registry for a bean of the given type. For instance:

Will lookup a bean with the id mySpecialFileSorter in the Registry.

Configuring parameter values using raw values, eg such as passwords

Available as of Camel 2.11

When configuring endpoint options using URI syntax, then the values is by default URI encoded. This can be a problem if you want to configure passwords and just use the value as is without any encoding. For example you may have a plus sign in the password, which would be decimal encoded by default.

So from Camel 2.11 onwards we made this easier as you can denote a parameter value to be raw using the following syntax RAW(value). eg the value starts with RAW( and then ends with the parenthesis ). Here is a little example:

In the above example, we have declare the password value as raw, and the actual password would be as typed, eg se+re?t&23.

Using property placeholders

Camel have extensive support for using property placeholders, which you can read more about here. For example in the ftp example above we can externalize the password to a .properties file.

For example configuring the property placeholder when using a XML DSL, where we declare the location of the .properties file. Though we can also define this in Java code. See the documentation for more details.

And the Camel route now refers to the placeholder using the {{ key }} notation:

And have a myftp.properties file with password. Notice we still define the RAW(value) style to ensure the password is used as is

We could still have used the RAW(value) in the Camel route instead:

And then we would need to remove the RAW from the properties file:

To understand more about property placeholders, read the documentation.

See Also

How do I import routes from other XML files

Available as of Camel 2.3

When defining routes in Camel using Xml Configuration you may want to define some routes in other XML files. For example you may have many routes and it may help to maintain the application if some of the routes are in separate XML files. You may also want to store common and reusable routes in other XML files, which you can simply import when needed.

In Camel 2.3 it is now possible to define routes outside <camelContext/> which you do in a new <routeContext/> tag.

Icon

Notice: When you use <routeContext> then they are separated, and cannot reuse existing <onException>, <intercept>, <dataFormats> and similar cross cutting functionality defined in the <camelContext>. In other words the <routeContext> is currently isolated. This may change in Camel 3.x.

For example we could have a file named myCoolRoutes.xml which contains a couple of routes as shown:

myCoolRoutes.xml

Then in your XML file which contains the CamelContext you can use Spring to import the myCoolRoute.xml file.
And then inside <camelContext/> you can refer to the <routeContext/> by its id as shown below:

Also notice that you can mix and match, having routes inside CamelContext and also externalized in RouteContext.

You can have as many <routeContextRef/> as you like.

Reusable routes

Icon

The routes defined in <routeContext/> can be reused by multiple <camelContext/>. However its only the definition which is reused. At runtime each CamelContext will create its own instance of the route based on the definition.

How do I add a component

You might first want to read Writing Components for a background in how to implement a new component.
Typically it means you write an implementation of the Component interface, usually deriving from DefaultComponent.

You can then register your component explicitly via

However you can use the auto-discovery feature of Camel where by Camel will automatically add a Component when an endpoint URI is used. To do this you would create a file called

with contents

(you can add other property configurations in there too if you like)

Then if you refer to an endpoint as foo://somethingOrOther Camel will auto-discover your component and register it.

The FooComponent can then be auto-injected with resources using the Injector, such as to support Spring based auto-wiring, or to support @Resource (EJB3 style) injection or Guice style @Inject injection.

Working with Spring XML

You can configure a component via Spring using the following mechanism...

Which allows you to configure a component using some name (activemq in the above example), then you can refer to the component using activemq:[queue:|topic:]destinationName.

If you want to add explicit Spring 2.x XML objects to your XML then you could use the xbean-spring which tries to automate most of the XML binding work for you; or you could look in camel-spring at CamelNamespaceHandler you'll see how we handle the Spring XML stuff (warning its kinda hairy code to look at (smile). If you wanted <fooComponent> to be a standard part of the core Camel schema then you'd hack that file to add your component & conftribute a patch to the camel XSD. Otherwise you could write your own namespace & schema if you prefer.

See Also

© 2004-2014 The Apache Software Foundation.
Apache Camel, Camel, Apache, the Apache feather logo, and the Apache Camel project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.
Graphic Design By Hiram