You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Antonin Stefanutti <an...@stefanutti.fr> on 2015/10/06 10:50:36 UTC
Camel CDI component improvements
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
Re: Camel CDI component improvements
Posted by Antonin Stefanutti <an...@stefanutti.fr>.
Yes, I focused on the core Camel CDI component.
I’ll work then on the testing module, samples and documentation. So much to do :)
> On 15 Jan 2016, at 14:44, Claus Ibsen <cl...@gmail.com> wrote:
>
> Hi
>
> Yay this is great news for users who want a microservice kinda way
> with just a simple cdi dependency injection framework.
>
> It would be cool to have a camel-test-cdi module separated from
> camel-cdi so we have similar "easy of testing" as with the other
> testing modules.
>
> On Thu, Jan 14, 2016 at 6:04 PM, Antonin Stefanutti
> <an...@stefanutti.fr> wrote:
>> Hi everyone,
>>
>> I’ve just completed the work improving the Camel CDI component and open PR https://github.com/apache/camel/pull/769.
>>
>> As the open PR is quite large, I’ve documented the most important contributions in https://issues.apache.org/jira/browse/CAMEL-9201.
>>
>> For those interested, I’d like to draw your attention to the non-backward compatible section at the bottom of the description that documents the few incompatibilities that this new version introduces and the rationale behind them. Feel free to review and discuss them if need.
>>
>> Antonin
>>
>>> On 08 Oct 2015, at 10:57, astefanutti <an...@stefanutti.fr> wrote:
>>>
>>> Hi Claus,
>>>
>>> Thanks for the quick reply. No worries.
>>>
>>> I've just created https://issues.apache.org/jira/browse/CAMEL-9201 to track
>>> discussion and progress on this.
>>>
>>> Antonin
>>>
>>>
>>>
>>> --
>>> View this message in context: http://camel.465427.n5.nabble.com/Camel-CDI-component-improvements-tp5772325p5772420.html
>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel CDI component improvements
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Yay this is great news for users who want a microservice kinda way
with just a simple cdi dependency injection framework.
It would be cool to have a camel-test-cdi module separated from
camel-cdi so we have similar "easy of testing" as with the other
testing modules.
On Thu, Jan 14, 2016 at 6:04 PM, Antonin Stefanutti
<an...@stefanutti.fr> wrote:
> Hi everyone,
>
> I’ve just completed the work improving the Camel CDI component and open PR https://github.com/apache/camel/pull/769.
>
> As the open PR is quite large, I’ve documented the most important contributions in https://issues.apache.org/jira/browse/CAMEL-9201.
>
> For those interested, I’d like to draw your attention to the non-backward compatible section at the bottom of the description that documents the few incompatibilities that this new version introduces and the rationale behind them. Feel free to review and discuss them if need.
>
> Antonin
>
>> On 08 Oct 2015, at 10:57, astefanutti <an...@stefanutti.fr> wrote:
>>
>> Hi Claus,
>>
>> Thanks for the quick reply. No worries.
>>
>> I've just created https://issues.apache.org/jira/browse/CAMEL-9201 to track
>> discussion and progress on this.
>>
>> Antonin
>>
>>
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.com/Camel-CDI-component-improvements-tp5772325p5772420.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel CDI component improvements
Posted by Antonin Stefanutti <an...@stefanutti.fr>.
Hi everyone,
I’ve just completed the work improving the Camel CDI component and open PR https://github.com/apache/camel/pull/769.
As the open PR is quite large, I’ve documented the most important contributions in https://issues.apache.org/jira/browse/CAMEL-9201.
For those interested, I’d like to draw your attention to the non-backward compatible section at the bottom of the description that documents the few incompatibilities that this new version introduces and the rationale behind them. Feel free to review and discuss them if need.
Antonin
> On 08 Oct 2015, at 10:57, astefanutti <an...@stefanutti.fr> wrote:
>
> Hi Claus,
>
> Thanks for the quick reply. No worries.
>
> I've just created https://issues.apache.org/jira/browse/CAMEL-9201 to track
> discussion and progress on this.
>
> Antonin
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-CDI-component-improvements-tp5772325p5772420.html
> Sent from the Camel Development mailing list archive at Nabble.com.
Re: Camel CDI component improvements
Posted by astefanutti <an...@stefanutti.fr>.
Hi Claus,
Thanks for the quick reply. No worries.
I've just created https://issues.apache.org/jira/browse/CAMEL-9201 to track
discussion and progress on this.
Antonin
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-CDI-component-improvements-tp5772325p5772420.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Camel CDI component improvements
Posted by Claus Ibsen <cl...@gmail.com>.
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
<an...@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