Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This is equivalent to writing:

 

Code Block
languagejava
@Inject
Event<String> event;

from("direct:event").process(new Processor() {
    @Override
    public void process(Exchange exchange) {
        event.fire(exchange.getBody(String.class));
    }
}).log("CDI event sent: ${body}");

Or using a Java 8 lambda expression:

Code Block
languagejava
@Inject
Event<String> event;

from("direct:event")
    .process(exchange -> event.fire(exchange.getIn().getBody(String.class)))
    .log("CDI event sent: ${body}");

The type variable T (resp. the qualifiers) of a particular CdiEventEndpoint<T> injection point are automatically translated into the parameterized event type (resp. into the event qualifiers) e.g.:

...

Besides, as the impedance between the typesafe nature of CDI and the dynamic nature of the Camel component model is quite high, it is not possible to create an instance of the CDI event Camel endpoint via URIs. Indeed, the URI format for the CDI event component is:

java
Code Block
language
cdi-event://PayloadType<T1,...,Tn>[?qualifiers=QualifierType1[,...[,QualifierTypeN]...]]

With the authority PayloadType (resp. the QualifierType) being the URI escaped fully qualified name of the payload (resp. qualifier) raw type followed by the type parameters section delimited by angle brackets for payload parameterized type. Which leads to unfriendly URIs, e.g.:

language
Code Block
java
cdi-event://org.apache.camel.cdi.seexample.pojo.EventPayload%3Cjava.lang.Integer%3E?qualifiers=org.apache.camel.cdi.se.qualifierexample.FooQualifier%2Corg.apache.camel.cdi.se.qualifierexample.BarQualifier

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.

...

Configuration properties

 

Camel bean integration

 

OSGi integration

 

Supported containers

...

The Camel CDI component is compatible with any CDI 1.0, CDI 1.1 and CDI 1.2 compliant runtime. It's been successfully tested against the following runtimes:

ContainerVersionRuntime
Weld SE1.1.28.FinalCDI 1.0 / Java SE 7
OpenWebBeans

1.2.7

CDI 1.0 / Java SE 7
Weld SE

2.3.2.Final

CDI 1.2 / Java SE 7
OpenWebBeans

1.6.2

CDI 1.2 / Java SE 7
WildFly8.2.1.FinalCDI 1.2 / Java EE 7
WildFly9.0.1.FinalCDI 1.2 / Java EE 7
Karaf2.4.4CDI 1.2 / OSGi 4 / PAX CDI
Karaf3.0.5CDI 1.2 / OSGi 5 / PAX CDI
Karaf4.0.4CDI 1.2 / OSGi 6 / PAX CDI

See Also