Hi Antonin Thanks for getting in touch with the Camel community.
We would love to have stronger and better CDI integration with Apache Camel. We have been a bit busy leading up to the upcoming Camel 2.16 release. But when that is out the door, I hope we can get time after wards to work with you on better CDI. Please dont take the lack of quick response as a "we dont care" but we busy with many things. I would suggest if you could log a JIRA ticket about better CDI and maybe post a link to this thread or move the conversation to the JIRA. A JIRA is a good way to get it on the roadmap and also not "forget" about it. On Tue, Oct 6, 2015 at 10:50 AM, Antonin Stefanutti <anto...@stefanutti.fr> wrote: > Hi All, > > I’ve been working on improving the Camel CDI integration over the last couple > of months. As it happens that a redesign was required to make it more 'CDI > spirit', I’ve done the heavy work in a separate project and documented the > improvements over the existing component from the Apache Camel codeline here: > https://github.com/astefanutti/camel-cdi#contribution. > > To have that improved version of the component contributed back into the > Apache Camel codeline, I’d like to have your opinion and guidance regarding > the question of its compatibility across existing (and potentially future) > CDI versions. At the moment, there exist 3 versions of the specification, > that are 1.0, 1.1 and 1.2. I originally wrote that improved version against > CDI 1.2, and with the CDI spec lead help, rewrote a CDI 1.0 compliant version > as a lot of people still use CDI 1.0 and cannot upgrade their environments. > > So far, I see two options to provide support for existing CDI versions: > - Have two separate Camel CDI components with the CDI version encoded in the > artifact ids, like camel-cdi-1-0 and camel-cdi-1-2 (compatible with both CDI > 1.1 and CDI 1.2), > - Have a single Camel CDI component relying on CDI 1.0 only features. > > The first approach would have the advantages of enabling the use of new CDI > features leading to much clearer code, better boot performance (and for > example avoiding some logging statements emitted by the CDI containers about > better lifecycle events usage). But it would have the disadvantage to let > that compatibility concern leak into the user space. An integrating project > would have to deal with it one way or another for its end-users. Besides, > what about the upcoming CDI 2.0 version… > > The second approach would have the advantage of simplicity for the users but > at the cost of code maintenance, evolvability / functionality (being stuck to > the oldest version features). > > I would tend to favor simplicity of use but I’d like to have your opinion on > that and make sure no other option exist to integrate that work into Camel > codeline and have it compatible with the largest CDI versions range at the > same time. > > Has that concern already been faced and answered for other components? Has it > been done already to deal with major Spring versions? > > Thanks for your input, > > Antonin > https://twitter.com/astefanut > https://github.com/astefanutti > -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2nd edition: https://www.manning.com/books/camel-in-action-second-edition
