...
But more fundamentally, that would prevent efficient binding between the endpoint instances and the observer methods as the CDI container doesn't have any ways of discovering the Camel context model during the deployment phase.
Camel XML configuration import
Available as of Camel 2.18
While CDI favors a typesafe dependency injection mechanism, it may be useful to reuse existing Camel XML configuration files into a Camel CDI application. In other use cases, it might be handy to rely on the Camel XML DSL to configure its Camel context(s).
You can use the @ImportResource
annotation that's provided by Camel CDI on any CDI beans and Camel CDI will automatically load the Camel XML configuration at the specified locations, e.g.:
Code Block | ||
---|---|---|
| ||
@ImportResource("camel-context.xml")
class MyBean {
} |
Camel CDI will load the resources at the specified locations from the classpath (other protocols may be added in the future).
Every CamelContext
elements and other Camel primitives from the imported resources are automatically deployed as CDI beans during the container bootstrap so that they benefit from the auto-configuration provided by Camel CDI and become available for injection at runtime. If such an element has an explicit id
attribute set, the corresponding CDI bean is qualified with the @Named
qualifier, e.g., given the following Camel XML configuration:
Code Block | ||
---|---|---|
| ||
<camelContext id="foo">
<endpoint id="bar" uri="seda:inbound">
<property key="queue" value="#queue"/>
<property key="concurrentConsumers" value="10"/>
</endpoint>
<camelContext/> |
The corresponding CDI beans are automatically deployed and can be injected, e.g.:
Code Block | ||
---|---|---|
| ||
@Inject
@ContextName("foo")
CamelContext context;
@Inject
@Named("bar")
Endpoint endpoint; |
Note that the CamelContext
beans are automatically qualified with both the Named
and ContextName
qualifiers. If the imported CamelContext
element doesn't have an id
attribute, the corresponding bean is deployed with the built-in Default
qualifier.
Conversely, CDI beans deployed in the application can be referred to from the Camel XML configuration, usually using the ref
attribute, e.g., given the following bean declared:
Code Block | ||
---|---|---|
| ||
@Produces
@Named("baz")
Processor processor = exchange -> exchange.getIn().setHeader("qux", "quux"); |
A reference to that bean can be declared in the imported Camel XML configuration, e.g.:
Code Block | ||
---|---|---|
| ||
<camelContext id="foo">
<route>
<from uri="..."/>
<process ref="baz"/>
</route>
<camelContext/> |
Auto-configured OSGi integration
...
Example | Description |
---|---|
camel-example-cdi | Illustrates how to work with Camel using CDI to configure components, endpoints and beans |
camel-example-cdi-metrics | Illustrates the integration between Camel, Dropwizard Metrics and CDI |
camel-example-cdi-properties | Illustrates the integration between Camel, DeltaSpike and CDI for configuration properties |
camel-example-cdi-osgi | A CDI application using the SJMS component that can be executed inside an OSGi container using PAX CDI |
camel-example-cdi-test | Demonstrates the testing features that are provided as part of the integration between Camel and CDI |
camel-example-cdi-rest-servlet | Illustrates the Camel REST DSL being used in a Web application that uses CDI as dependency injection framework |
camel-example-cdi-xml | Illustrates the use of Camel XML configuration files into a Camel CDI application |
camel-example-widget-gadget-cdi | The Widget and Gadget use-case from the EIP book implemented in Java with CDI dependency injection |
camel-example-swagger-cdi | An example using REST DSL and Swagger Java with CDI |
...