Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
Since version 2.10.0 of Camel, the Camel CDI component hasn't been actively maintained and suffers from few design flaws that impede improvements and new features.
Over the last couple of months, work has been done to refactor and improve the existing Camel CDI component. However, given that a redesign was required to make it more CDI spirit, the heavy work has been done in a separate project and the rational for an overhaul and the contribution list documented here: https://github.com/astefanutti/camel-cdi.
As people started using and contributing to it, it'd be better to have that improved version contributed back to the project as soon as possible to avoid diverging to much.
That new version of the Camel CDI component provides the following:
New features
- CDI events Camel endpoint
- Camel events to CDI events bridge
- Type converter beans
- OSGi integration
Improvements
- Better Camel context customisation and lifecycle
- Better multiple Camel contexts support
- @Uri and @Mock Endpoint Qualifiers Unification
- Dependency on DeltaSpike has been removed (only remaining for Main support)
Compatibility
- CDI 1.0, 1.1, 1.2
- Java SE: Weld 1.x, Weld 2.x, OpenWebBeans 1.2.x, 1.6.x
- Java EE: WildFly 8.x, 9.x, WildFly Camel
- OSGi: Karaf 4
Test coverage
- 100+ test cases
- 90% test coverage
- Profiles for (Weld, OpenWebBeans) x (CDI 1.0, CDI 1.2)
Non-backward compatibility
Compile time
- The @ContextName qualifier does not have a default empty value anymore as it is irrelevant
- The CdiPropertiesComponent class has been removed, the standard PropertiesComponent can be used instead
Run time
- DeltaSpike is not used anymore for the sourcing of the configuration properties. This new version is agnostic to any configuration sourcing mechanism and delegates that concern to the application so that it can declare a custom PropertiesComponent bean whose sourcing is tailored to its need. DeltaSpike can still be easily used by the application by declaring a PropertiesComponent bean configured with a PropertiesResolver / PropertiesParser relying on DeltaSpike. See https://github.com/apache/camel/tree/83d0d1b01db6a6df7953a2a14342367d0775a80c/examples/camel-example-cdi-properties for an example.
More details can be found in https://github.com/astefanutti/camel-cdi#contribution.
Attachments
Issue Links
- contains
-
CAMEL-9336 camel-cdi - Should add routes to CamelContext before its started
- Resolved
-
CAMEL-6336 camel cdi uses postconstruct to inject in cdi beans
- Resolved
-
CAMEL-7760 WELD-001409: Ambiguous dependencies for type CdiCamelContext
- Resolved
-
CAMEL-5408 Extend CDI component with support for events
- Resolved
-
CAMEL-5553 camel-cdi - support injection of Endpoint and @Produce @Consume annotations
- Resolved
-
CAMEL-5986 Property placeholders do not work for CDI injection
- Resolved
-
CAMEL-5742 camel-cdi - The @ContextName should only refer to a CamelContext and not create a new CamelContext on the fly
- Resolved
-
CAMEL-6338 camel-cdi shouldn't use deltapsike bean manager provider in the CamelExtension
- Resolved
-
CAMEL-6937 BeanManager cannot be retrieved when camel cdi is deployed in Karaf
- Resolved
-
CAMEL-6095 Fix camel-cdi when running in OSGi with pax-cdi
- Resolved
- is depended upon by
-
CAMEL-9630 Add missing literals to Camel CDI
- Resolved
- is related to
-
CAMEL-9339 camel-cdi - If starting camel-cdi main and no camel found then log a WARN about this
- Resolved
- is required by
-
CAMEL-8325 Spring Boot and CDI integration don't detect duplicate routes, should support earlier context configuration
- Resolved
- supercedes
-
CAMEL-5553 camel-cdi - support injection of Endpoint and @Produce @Consume annotations
- Resolved