You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Hadrian Zbarcea <hz...@gmail.com> on 2010/10/18 19:28:39 UTC
[DISCUSS] Some thoughts about the architecture of camel
I changed the thread name to [discuss].
I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
What I'd propose Christian is to add your proposal to the roadmap [1]. I will do the same for the dsl idea. There at least 2 ideas for dsl's built on top of the camel dsl (scheduling and debugging) that make me even more interested in coming up with a better solution.
Once we get some traction on the main refactoring ideas I'd suggest starting one (or more) branches and start hacking, because there's not a whole lot of time left if we want to meet our target.
Cheers,
Hadrian
[1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
> Hi all,
>
> I will have some free time in december as I am changing my employer. So I am planning to work a little on some architectural improvements for camel 3.0.0. As these things are very critical to the stability of camel I would like to get feedback before I start any substantial work.
>
> As you surely know currently camel-core is quite tangled. So it is quite difficult where to start. Some time ago I proposed some improvements to simply reduce those dependency cycles. As I now know a lot more about camel I think that this simple aproach will not really work. So this time I want to do this a little more structured. So I start with two simple goals:
>
> "The camel components should know as little as possible about camel core"
>
> "The classes needed to setup camel should be separate from the things needed at run time"
>
> So why should this be important? Currently components depend on camel-core as a whole and there are no further rules which classes the components should use and which classes should be private to core. Even classes from the impl package are needed. So this means that any refactoring we do in camel core could affect all components. As camel is growing steadily this can become quite problematic.
>
> So my idea would be to split camel-core into three parts:
>
> api, builder, impl
>
> These should be structured in a way that these big building blocks do not have cyclic dependencies. Any other cycles can be ignored in this step.
>
> As allowed depdencies I propose ( "->" means may use, depends on):
>
> * -> api
> end user config -> builder
> builder -> impl
>
> I think the first thing we should do is to discuss and reach a consensus about a basic architecure and rules like above. Then the next step is to assign each package of core to one of the basic parts. Then the next step is to resolve cycles between the parts.
>
> What do you think about these ideas?
>
> Thanks
>
> Christian
>
> Christian Schneider
> Informationsverarbeitung
> Business Solutions
> Handel und Dispatching
>
> Tel : +49-(0)721-63-15482
>
> EnBW Systeme Infrastruktur Support GmbH
> Sitz der Gesellschaft: Karlsruhe
> Handelsregister: Amtsgericht Mannheim ‑ HRB 108550
> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>
>
>
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Johan Edstrom <se...@gmail.com>.
Could you post a "LOW HANGING FRUIT"
Page that us mortals could start hitting?
On Oct 18, 2010, at 10:23 PM, Claus Ibsen wrote:
> Hi
>
> I think the idea is really great, but I think the timing for this is
> *not* the right spot.
>
> And by saying that I mean the goal of Camel 3.0 is to have a short
> development cycle (not like 2.0 which took a long time).
> And as a minimum (IMHO):
> - To upgrade to JDK 1.6+,
> - Spring 3.0+,
> - To optimize the router internally,
> - And to switch to slf4j logger (*)
> - Keeping backwards compatibility as much as possible with 2.x is paramount
>
> Switching to slf4j instead of commons logging, allows us to use the
> MDC logging feature.
> This allows us to push information to the logs such as message id,
> transaction id etc. which can more easily correlate logs, not only
> with Camel alone, but also with other projects such as ActiveMQ, SMX
> etc.
>
>
> On top of that we now have many 3rd party projects which integrate out
> of the box with Camel, so changing the package structure in camel-core
> will break their integration. Which means they may not take up the
> effort to support both Camel 2.x/3.x.
>
> However I do think we should take the effort and pick up the low
> hanging fruits. I am sure there could be a couple of tangles which can
> be identified and fixed in Camel 3.0, without breaking backwards
> compatibility.
>
> I think doing this is something for Camel 4 or 5 or 6 (or whatever
> future version it may be) when or if we change to use Scala and use
> some other framework as foundation. There are cool stuff being
> developed for ActiveMQ 6 which are potential as a backbone for route
> messages. And it has a much better threading model which Camel can
> benefit as well.
>
> Anyway practical works beats theory, so setting up a branch in the
> sandbox to do experiments is a great idea.
>
> But its very important that we keep backwards compatibility with Camel
> 3.0. There are so many people started using Camel 2.x now so we should
> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
> 2.x but now on JDK 1.6 and with X other internal upgrades.
>
> Okay my first cup of coffee is ready, so beware this mail was written
> before I got "my first fix".
>
>
>
> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> I changed the thread name to [discuss].
>>
>> I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
>>
>> What I'd propose Christian is to add your proposal to the roadmap [1]. I will do the same for the dsl idea. There at least 2 ideas for dsl's built on top of the camel dsl (scheduling and debugging) that make me even more interested in coming up with a better solution.
>>
>> Once we get some traction on the main refactoring ideas I'd suggest starting one (or more) branches and start hacking, because there's not a whole lot of time left if we want to meet our target.
>>
>> Cheers,
>> Hadrian
>>
>> [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>>
>>
>>
>> On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>>
>>> Hi all,
>>>
>>> I will have some free time in december as I am changing my employer. So I am planning to work a little on some architectural improvements for camel 3.0.0. As these things are very critical to the stability of camel I would like to get feedback before I start any substantial work.
>>>
>>> As you surely know currently camel-core is quite tangled. So it is quite difficult where to start. Some time ago I proposed some improvements to simply reduce those dependency cycles. As I now know a lot more about camel I think that this simple aproach will not really work. So this time I want to do this a little more structured. So I start with two simple goals:
>>>
>>> "The camel components should know as little as possible about camel core"
>>>
>>> "The classes needed to setup camel should be separate from the things needed at run time"
>>>
>>> So why should this be important? Currently components depend on camel-core as a whole and there are no further rules which classes the components should use and which classes should be private to core. Even classes from the impl package are needed. So this means that any refactoring we do in camel core could affect all components. As camel is growing steadily this can become quite problematic.
>>>
>>> So my idea would be to split camel-core into three parts:
>>>
>>> api, builder, impl
>>>
>>> These should be structured in a way that these big building blocks do not have cyclic dependencies. Any other cycles can be ignored in this step.
>>>
>>> As allowed depdencies I propose ( "->" means may use, depends on):
>>>
>>> * -> api
>>> end user config -> builder
>>> builder -> impl
>>>
>>> I think the first thing we should do is to discuss and reach a consensus about a basic architecure and rules like above. Then the next step is to assign each package of core to one of the basic parts. Then the next step is to resolve cycles between the parts.
>>>
>>> What do you think about these ideas?
>>>
>>> Thanks
>>>
>>> Christian
>>>
>>> Christian Schneider
>>> Informationsverarbeitung
>>> Business Solutions
>>> Handel und Dispatching
>>>
>>> Tel : +49-(0)721-63-15482
>>>
>>> EnBW Systeme Infrastruktur Support GmbH
>>> Sitz der Gesellschaft: Karlsruhe
>>> Handelsregister: Amtsgericht Mannheim - HRB 108550
>>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>>> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
Johan Edstrom
joed@opennms.org
They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety.
Benjamin Franklin, Historical Review of Pennsylvania, 1759
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I don't think the idea of 2 major releases in a year will fly. I am personally against it until somebody convinces me otherwise.
I agree as well, that camel should move to spring 3.0. I am not convinced that it absolutely implies a major release of camel (3.0). At this time I don't have a strong preference on this issue.
Hadrian
On Oct 19, 2010, at 12:34 PM, Christian Schneider wrote:
> I have no problem with a 3.0 release for spring and jkd upgrades. I also like the idea that camel 3.x needs spring 3.x.
>
> To also be able to do some breaking changes in the near future I propose to do a 4.0 release earlier than planned. I think end of Q2 2011 could be reasonable. We can start experimenting in a branch asap and try to settle on the featureset for 4.0 till end of Q1. Then we should have enough time to make it stable.
>
> Best regards
>
> Christian
>
>
> Am 19.10.2010 16:21, schrieb James Strachan:
>> On 19 October 2010 15:06, Hadrian Zbarcea<hz...@gmail.com> wrote:
>>> If you think it's a good idea, and I agree, then 3.0 *is* the right time to do it. It's some 5-6 months away, there's plenty of time and I expect us to get a lot of help from the growing community.
>>>
>>> Pushing this for 4.0 is much less realistic, we won't have another major release in 2011. I also agree that we should be backwards compatible as much as possible, but the truth is this is a major version and should come with major improvements. Moving to a major release of a dependent jar, is not a major improvement we do it all the time (even if the dependency is spring).
>>>
>>> We need to first agree how 3.0 will be a major improvement.
>> We've already said, moving (like many of our dependencies) to Spring 3
>> and JDK 6 is a pretty big jump folks need to be aware of; its not a
>> minor incremental feature release.
>>
>>
>>> Setting a release time and have that contain whatever we manage to code until then sounds to me like Microsoft in its early days.
>> I've no idea what you're talking about to be honest. Why are you so
>> hung up with clinging to 2.6 when we're making a clear, big dependency
>> jump to Java 6 and Spring 3?
>>
>> Try putting yourself in the position of a user; in Camel up to now you
>> can move from 2.x to 2.(x+1) without worrying too much about it, it
>> mostly just works. For 3.x we want folks to ponder for second about
>> JDK and Spring dependencies. OK?
>>
>
> --
> ----
> http://www.liquid-reality.de
>
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Christian Schneider <ch...@die-schneider.net>.
I have no problem with a 3.0 release for spring and jkd upgrades. I
also like the idea that camel 3.x needs spring 3.x.
To also be able to do some breaking changes in the near future I propose
to do a 4.0 release earlier than planned. I think end of Q2 2011 could
be reasonable. We can start experimenting in a branch asap and try to
settle on the featureset for 4.0 till end of Q1. Then we should have
enough time to make it stable.
Best regards
Christian
Am 19.10.2010 16:21, schrieb James Strachan:
> On 19 October 2010 15:06, Hadrian Zbarcea<hz...@gmail.com> wrote:
>> If you think it's a good idea, and I agree, then 3.0 *is* the right time to do it. It's some 5-6 months away, there's plenty of time and I expect us to get a lot of help from the growing community.
>>
>> Pushing this for 4.0 is much less realistic, we won't have another major release in 2011. I also agree that we should be backwards compatible as much as possible, but the truth is this is a major version and should come with major improvements. Moving to a major release of a dependent jar, is not a major improvement we do it all the time (even if the dependency is spring).
>>
>> We need to first agree how 3.0 will be a major improvement.
> We've already said, moving (like many of our dependencies) to Spring 3
> and JDK 6 is a pretty big jump folks need to be aware of; its not a
> minor incremental feature release.
>
>
>> Setting a release time and have that contain whatever we manage to code until then sounds to me like Microsoft in its early days.
> I've no idea what you're talking about to be honest. Why are you so
> hung up with clinging to 2.6 when we're making a clear, big dependency
> jump to Java 6 and Spring 3?
>
> Try putting yourself in the position of a user; in Camel up to now you
> can move from 2.x to 2.(x+1) without worrying too much about it, it
> mostly just works. For 3.x we want folks to ponder for second about
> JDK and Spring dependencies. OK?
>
--
----
http://www.liquid-reality.de
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I feel that we're mostly in violent agreement :). Comments inline.
Hadrian
On Oct 19, 2010, at 10:21 AM, James Strachan wrote:
> On 19 October 2010 15:06, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> If you think it's a good idea, and I agree, then 3.0 *is* the right time to do it. It's some 5-6 months away, there's plenty of time and I expect us to get a lot of help from the growing community.
>>
>> Pushing this for 4.0 is much less realistic, we won't have another major release in 2011. I also agree that we should be backwards compatible as much as possible, but the truth is this is a major version and should come with major improvements. Moving to a major release of a dependent jar, is not a major improvement we do it all the time (even if the dependency is spring).
>>
>> We need to first agree how 3.0 will be a major improvement.
>
> We've already said, moving (like many of our dependencies) to Spring 3
> and JDK 6 is a pretty big jump folks need to be aware of; its not a
> minor incremental feature release.
I meant camel 3.0, right?
>> Setting a release time and have that contain whatever we manage to code until then sounds to me like Microsoft in its early days.
>
> I've no idea what you're talking about to be honest. Why are you so
> hung up with clinging to 2.6 when we're making a clear, big dependency
> jump to Java 6 and Spring 3?
I am not clinging to anything, I stated that moving to jdk6 is very possible in 2.6, or 2.7, or 3.0. Not so much for a maintenance release like 2.5.x for instance. Maybe we should consider having more maintenance releases like other projects (amq for instance). That said, personally I would love to move to jdk6 as soon as possible (hence my mentioning of camel 2.6). I had quite a bunch of failing java5 builds that I wasted time on with this release, and almost all developers use only java6 anyway. What java version are you using?
>
> Try putting yourself in the position of a user; in Camel up to now you
> can move from 2.x to 2.(x+1) without worrying too much about it, it
> mostly just works. For 3.x we want folks to ponder for second about
> JDK and Spring dependencies. OK?
Oh, believe me, I do :).
Fair enough, I agree with that. And while they're at it, they can still use 2.x for as long as they want, 2.x will be actively maintained until at least the and of 2011, we discussed that.
There is also no absolute must to be fully backwards compatible in camel 3.0. Heck, in some respects we are not fully backwards compatible between minor releases. Highly desired though, I agree.
On top of all that, there is no agreement on what should be done in camel 3.0 (as the wiki page clearly states as well). People are throwing in proposals, and now's definitely the right time, and we are respectfully considering them, and then we'll make decisions based on lazy consensus or other vote. I find the camel community a highly educated bunch, we can talk each other into (or out of) different proposals and solutions.
Let's discuss our proposals and options. If anybody has other proposals, put them on the table. I hope we can clarify most of it in the next weeks and start hacking. Apachecon would be a great place to meet face to face and agree on details, btw.
Cheers,
Hadrian
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by James Strachan <ja...@gmail.com>.
On 19 October 2010 15:06, Hadrian Zbarcea <hz...@gmail.com> wrote:
> If you think it's a good idea, and I agree, then 3.0 *is* the right time to do it. It's some 5-6 months away, there's plenty of time and I expect us to get a lot of help from the growing community.
>
> Pushing this for 4.0 is much less realistic, we won't have another major release in 2011. I also agree that we should be backwards compatible as much as possible, but the truth is this is a major version and should come with major improvements. Moving to a major release of a dependent jar, is not a major improvement we do it all the time (even if the dependency is spring).
>
> We need to first agree how 3.0 will be a major improvement.
We've already said, moving (like many of our dependencies) to Spring 3
and JDK 6 is a pretty big jump folks need to be aware of; its not a
minor incremental feature release.
> Setting a release time and have that contain whatever we manage to code until then sounds to me like Microsoft in its early days.
I've no idea what you're talking about to be honest. Why are you so
hung up with clinging to 2.6 when we're making a clear, big dependency
jump to Java 6 and Spring 3?
Try putting yourself in the position of a user; in Camel up to now you
can move from 2.x to 2.(x+1) without worrying too much about it, it
mostly just works. For 3.x we want folks to ponder for second about
JDK and Spring dependencies. OK?
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Hadrian Zbarcea <hz...@gmail.com>.
If you think it's a good idea, and I agree, then 3.0 *is* the right time to do it. It's some 5-6 months away, there's plenty of time and I expect us to get a lot of help from the growing community.
Pushing this for 4.0 is much less realistic, we won't have another major release in 2011. I also agree that we should be backwards compatible as much as possible, but the truth is this is a major version and should come with major improvements. Moving to a major release of a dependent jar, is not a major improvement we do it all the time (even if the dependency is spring).
We need to first agree how 3.0 will be a major improvement. Setting a release time and have that contain whatever we manage to code until then sounds to me like Microsoft in its early days.
Hadrian
On Oct 19, 2010, at 12:23 AM, Claus Ibsen wrote:
> Hi
>
> I think the idea is really great, but I think the timing for this is
> *not* the right spot.
>
> And by saying that I mean the goal of Camel 3.0 is to have a short
> development cycle (not like 2.0 which took a long time).
> And as a minimum (IMHO):
> - To upgrade to JDK 1.6+,
> - Spring 3.0+,
> - To optimize the router internally,
> - And to switch to slf4j logger (*)
> - Keeping backwards compatibility as much as possible with 2.x is paramount
>
> Switching to slf4j instead of commons logging, allows us to use the
> MDC logging feature.
> This allows us to push information to the logs such as message id,
> transaction id etc. which can more easily correlate logs, not only
> with Camel alone, but also with other projects such as ActiveMQ, SMX
> etc.
>
>
> On top of that we now have many 3rd party projects which integrate out
> of the box with Camel, so changing the package structure in camel-core
> will break their integration. Which means they may not take up the
> effort to support both Camel 2.x/3.x.
>
> However I do think we should take the effort and pick up the low
> hanging fruits. I am sure there could be a couple of tangles which can
> be identified and fixed in Camel 3.0, without breaking backwards
> compatibility.
>
> I think doing this is something for Camel 4 or 5 or 6 (or whatever
> future version it may be) when or if we change to use Scala and use
> some other framework as foundation. There are cool stuff being
> developed for ActiveMQ 6 which are potential as a backbone for route
> messages. And it has a much better threading model which Camel can
> benefit as well.
>
> Anyway practical works beats theory, so setting up a branch in the
> sandbox to do experiments is a great idea.
>
> But its very important that we keep backwards compatibility with Camel
> 3.0. There are so many people started using Camel 2.x now so we should
> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
> 2.x but now on JDK 1.6 and with X other internal upgrades.
>
> Okay my first cup of coffee is ready, so beware this mail was written
> before I got "my first fix".
>
>
>
> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> I changed the thread name to [discuss].
>>
>> I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
>>
>> What I'd propose Christian is to add your proposal to the roadmap [1]. I will do the same for the dsl idea. There at least 2 ideas for dsl's built on top of the camel dsl (scheduling and debugging) that make me even more interested in coming up with a better solution.
>>
>> Once we get some traction on the main refactoring ideas I'd suggest starting one (or more) branches and start hacking, because there's not a whole lot of time left if we want to meet our target.
>>
>> Cheers,
>> Hadrian
>>
>> [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>>
>>
>>
>> On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>>
>>> Hi all,
>>>
>>> I will have some free time in december as I am changing my employer. So I am planning to work a little on some architectural improvements for camel 3.0.0. As these things are very critical to the stability of camel I would like to get feedback before I start any substantial work.
>>>
>>> As you surely know currently camel-core is quite tangled. So it is quite difficult where to start. Some time ago I proposed some improvements to simply reduce those dependency cycles. As I now know a lot more about camel I think that this simple aproach will not really work. So this time I want to do this a little more structured. So I start with two simple goals:
>>>
>>> "The camel components should know as little as possible about camel core"
>>>
>>> "The classes needed to setup camel should be separate from the things needed at run time"
>>>
>>> So why should this be important? Currently components depend on camel-core as a whole and there are no further rules which classes the components should use and which classes should be private to core. Even classes from the impl package are needed. So this means that any refactoring we do in camel core could affect all components. As camel is growing steadily this can become quite problematic.
>>>
>>> So my idea would be to split camel-core into three parts:
>>>
>>> api, builder, impl
>>>
>>> These should be structured in a way that these big building blocks do not have cyclic dependencies. Any other cycles can be ignored in this step.
>>>
>>> As allowed depdencies I propose ( "->" means may use, depends on):
>>>
>>> * -> api
>>> end user config -> builder
>>> builder -> impl
>>>
>>> I think the first thing we should do is to discuss and reach a consensus about a basic architecure and rules like above. Then the next step is to assign each package of core to one of the basic parts. Then the next step is to resolve cycles between the parts.
>>>
>>> What do you think about these ideas?
>>>
>>> Thanks
>>>
>>> Christian
>>>
>>> Christian Schneider
>>> Informationsverarbeitung
>>> Business Solutions
>>> Handel und Dispatching
>>>
>>> Tel : +49-(0)721-63-15482
>>>
>>> EnBW Systeme Infrastruktur Support GmbH
>>> Sitz der Gesellschaft: Karlsruhe
>>> Handelsregister: Amtsgericht Mannheim - HRB 108550
>>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>>> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Oct 19, 2010 at 6:58 AM, Martin Krasser <kr...@googlemail.com> wrote:
> +1 for being fully backwards compatible. I've many projects running on
> Camel 2.x and would like to benefit from Camel 3.x features without doing
> any (bigger) changes.
> +1 for making a bigger refactoring when going for a more idiomatic Scala
> (DSL) support (with more idiomatic I mean more FP-style e.g. higher order
> functions as combinators in the DSL etc.)
>
> I think it might be useful if we're going to write some more load- and
> stress tests for more frequently used Camel components (jetty, jms etc.) and
> camel-core and run them on a weekly basis, for example. This is not only to
> ensure correct behaviour under load: I've also had several customers in the
> past that where asking for performance numbers. I know that performance
> numbers make most sense for complete applications, but having a reference
> for individual application parts (e.g. raw throughput of jetty consumer
> endpoints) can be useful as well. It would also allow us to detect
> performance decreases more easily (e.g. after refactorings).
>
Good idea about the load tests.
If we can't make them easily run on some CI servers we can at least
run them locally to keep an eye on it.
>
> Am 19.10.10 06:23, schrieb Claus Ibsen:
>>
>> Hi
>>
>> I think the idea is really great, but I think the timing for this is
>> *not* the right spot.
>>
>> And by saying that I mean the goal of Camel 3.0 is to have a short
>> development cycle (not like 2.0 which took a long time).
>> And as a minimum (IMHO):
>> - To upgrade to JDK 1.6+,
>> - Spring 3.0+,
>> - To optimize the router internally,
>> - And to switch to slf4j logger (*)
>> - Keeping backwards compatibility as much as possible with 2.x is
>> paramount
>>
>> Switching to slf4j instead of commons logging, allows us to use the
>> MDC logging feature.
>> This allows us to push information to the logs such as message id,
>> transaction id etc. which can more easily correlate logs, not only
>> with Camel alone, but also with other projects such as ActiveMQ, SMX
>> etc.
>>
>>
>> On top of that we now have many 3rd party projects which integrate out
>> of the box with Camel, so changing the package structure in camel-core
>> will break their integration. Which means they may not take up the
>> effort to support both Camel 2.x/3.x.
>>
>> However I do think we should take the effort and pick up the low
>> hanging fruits. I am sure there could be a couple of tangles which can
>> be identified and fixed in Camel 3.0, without breaking backwards
>> compatibility.
>>
>> I think doing this is something for Camel 4 or 5 or 6 (or whatever
>> future version it may be) when or if we change to use Scala and use
>> some other framework as foundation. There are cool stuff being
>> developed for ActiveMQ 6 which are potential as a backbone for route
>> messages. And it has a much better threading model which Camel can
>> benefit as well.
>>
>> Anyway practical works beats theory, so setting up a branch in the
>> sandbox to do experiments is a great idea.
>>
>> But its very important that we keep backwards compatibility with Camel
>> 3.0. There are so many people started using Camel 2.x now so we should
>> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
>> 2.x but now on JDK 1.6 and with X other internal upgrades.
>>
>> Okay my first cup of coffee is ready, so beware this mail was written
>> before I got "my first fix".
>>
>>
>>
>> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea<hz...@gmail.com>
>> wrote:
>>>
>>> I changed the thread name to [discuss].
>>>
>>> I like that idea and it's something we contemplated in the past. This
>>> will bring back the idea of getting the dsl out of core as well.
>>>
>>> What I'd propose Christian is to add your proposal to the roadmap [1]. I
>>> will do the same for the dsl idea. There at least 2 ideas for dsl's built on
>>> top of the camel dsl (scheduling and debugging) that make me even more
>>> interested in coming up with a better solution.
>>>
>>> Once we get some traction on the main refactoring ideas I'd suggest
>>> starting one (or more) branches and start hacking, because there's not a
>>> whole lot of time left if we want to meet our target.
>>>
>>> Cheers,
>>> Hadrian
>>>
>>> [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>>>
>>>
>>>
>>> On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>>>
>>>> Hi all,
>>>>
>>>> I will have some free time in december as I am changing my employer. So
>>>> I am planning to work a little on some architectural improvements for camel
>>>> 3.0.0. As these things are very critical to the stability of camel I would
>>>> like to get feedback before I start any substantial work.
>>>>
>>>> As you surely know currently camel-core is quite tangled. So it is quite
>>>> difficult where to start. Some time ago I proposed some improvements to
>>>> simply reduce those dependency cycles. As I now know a lot more about camel
>>>> I think that this simple aproach will not really work. So this time I want
>>>> to do this a little more structured. So I start with two simple goals:
>>>>
>>>> "The camel components should know as little as possible about camel
>>>> core"
>>>>
>>>> "The classes needed to setup camel should be separate from the things
>>>> needed at run time"
>>>>
>>>> So why should this be important? Currently components depend on
>>>> camel-core as a whole and there are no further rules which classes the
>>>> components should use and which classes should be private to core. Even
>>>> classes from the impl package are needed. So this means that any refactoring
>>>> we do in camel core could affect all components. As camel is growing
>>>> steadily this can become quite problematic.
>>>>
>>>> So my idea would be to split camel-core into three parts:
>>>>
>>>> api, builder, impl
>>>>
>>>> These should be structured in a way that these big building blocks do
>>>> not have cyclic dependencies. Any other cycles can be ignored in this step.
>>>>
>>>> As allowed depdencies I propose ( "->" means may use, depends on):
>>>>
>>>> * -> api
>>>> end user config -> builder
>>>> builder -> impl
>>>>
>>>> I think the first thing we should do is to discuss and reach a consensus
>>>> about a basic architecure and rules like above. Then the next step is to
>>>> assign each package of core to one of the basic parts. Then the next step is
>>>> to resolve cycles between the parts.
>>>>
>>>> What do you think about these ideas?
>>>>
>>>> Thanks
>>>>
>>>> Christian
>>>>
>>>> Christian Schneider
>>>> Informationsverarbeitung
>>>> Business Solutions
>>>> Handel und Dispatching
>>>>
>>>> Tel : +49-(0)721-63-15482
>>>>
>>>> EnBW Systeme Infrastruktur Support GmbH
>>>> Sitz der Gesellschaft: Karlsruhe
>>>> Handelsregister: Amtsgericht Mannheim - HRB 108550
>>>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>>>> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
> --
> Martin Krasser
>
> blog: http://krasserm.blogspot.com
> code: http://github.com/krasserm
> twitter: http://twitter.com/mrt1nz
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Martin Krasser <kr...@googlemail.com>.
+1 for being fully backwards compatible. I've many projects running on
Camel 2.x and would like to benefit from Camel 3.x features without
doing any (bigger) changes.
+1 for making a bigger refactoring when going for a more idiomatic Scala
(DSL) support (with more idiomatic I mean more FP-style e.g. higher
order functions as combinators in the DSL etc.)
I think it might be useful if we're going to write some more load- and
stress tests for more frequently used Camel components (jetty, jms etc.)
and camel-core and run them on a weekly basis, for example. This is not
only to ensure correct behaviour under load: I've also had several
customers in the past that where asking for performance numbers. I know
that performance numbers make most sense for complete applications, but
having a reference for individual application parts (e.g. raw throughput
of jetty consumer endpoints) can be useful as well. It would also allow
us to detect performance decreases more easily (e.g. after refactorings).
Am 19.10.10 06:23, schrieb Claus Ibsen:
> Hi
>
> I think the idea is really great, but I think the timing for this is
> *not* the right spot.
>
> And by saying that I mean the goal of Camel 3.0 is to have a short
> development cycle (not like 2.0 which took a long time).
> And as a minimum (IMHO):
> - To upgrade to JDK 1.6+,
> - Spring 3.0+,
> - To optimize the router internally,
> - And to switch to slf4j logger (*)
> - Keeping backwards compatibility as much as possible with 2.x is paramount
>
> Switching to slf4j instead of commons logging, allows us to use the
> MDC logging feature.
> This allows us to push information to the logs such as message id,
> transaction id etc. which can more easily correlate logs, not only
> with Camel alone, but also with other projects such as ActiveMQ, SMX
> etc.
>
>
> On top of that we now have many 3rd party projects which integrate out
> of the box with Camel, so changing the package structure in camel-core
> will break their integration. Which means they may not take up the
> effort to support both Camel 2.x/3.x.
>
> However I do think we should take the effort and pick up the low
> hanging fruits. I am sure there could be a couple of tangles which can
> be identified and fixed in Camel 3.0, without breaking backwards
> compatibility.
>
> I think doing this is something for Camel 4 or 5 or 6 (or whatever
> future version it may be) when or if we change to use Scala and use
> some other framework as foundation. There are cool stuff being
> developed for ActiveMQ 6 which are potential as a backbone for route
> messages. And it has a much better threading model which Camel can
> benefit as well.
>
> Anyway practical works beats theory, so setting up a branch in the
> sandbox to do experiments is a great idea.
>
> But its very important that we keep backwards compatibility with Camel
> 3.0. There are so many people started using Camel 2.x now so we should
> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
> 2.x but now on JDK 1.6 and with X other internal upgrades.
>
> Okay my first cup of coffee is ready, so beware this mail was written
> before I got "my first fix".
>
>
>
> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea<hz...@gmail.com> wrote:
>> I changed the thread name to [discuss].
>>
>> I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
>>
>> What I'd propose Christian is to add your proposal to the roadmap [1]. I will do the same for the dsl idea. There at least 2 ideas for dsl's built on top of the camel dsl (scheduling and debugging) that make me even more interested in coming up with a better solution.
>>
>> Once we get some traction on the main refactoring ideas I'd suggest starting one (or more) branches and start hacking, because there's not a whole lot of time left if we want to meet our target.
>>
>> Cheers,
>> Hadrian
>>
>> [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>>
>>
>>
>> On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>>
>>> Hi all,
>>>
>>> I will have some free time in december as I am changing my employer. So I am planning to work a little on some architectural improvements for camel 3.0.0. As these things are very critical to the stability of camel I would like to get feedback before I start any substantial work.
>>>
>>> As you surely know currently camel-core is quite tangled. So it is quite difficult where to start. Some time ago I proposed some improvements to simply reduce those dependency cycles. As I now know a lot more about camel I think that this simple aproach will not really work. So this time I want to do this a little more structured. So I start with two simple goals:
>>>
>>> "The camel components should know as little as possible about camel core"
>>>
>>> "The classes needed to setup camel should be separate from the things needed at run time"
>>>
>>> So why should this be important? Currently components depend on camel-core as a whole and there are no further rules which classes the components should use and which classes should be private to core. Even classes from the impl package are needed. So this means that any refactoring we do in camel core could affect all components. As camel is growing steadily this can become quite problematic.
>>>
>>> So my idea would be to split camel-core into three parts:
>>>
>>> api, builder, impl
>>>
>>> These should be structured in a way that these big building blocks do not have cyclic dependencies. Any other cycles can be ignored in this step.
>>>
>>> As allowed depdencies I propose ( "->" means may use, depends on):
>>>
>>> * -> api
>>> end user config -> builder
>>> builder -> impl
>>>
>>> I think the first thing we should do is to discuss and reach a consensus about a basic architecure and rules like above. Then the next step is to assign each package of core to one of the basic parts. Then the next step is to resolve cycles between the parts.
>>>
>>> What do you think about these ideas?
>>>
>>> Thanks
>>>
>>> Christian
>>>
>>> Christian Schneider
>>> Informationsverarbeitung
>>> Business Solutions
>>> Handel und Dispatching
>>>
>>> Tel : +49-(0)721-63-15482
>>>
>>> EnBW Systeme Infrastruktur Support GmbH
>>> Sitz der Gesellschaft: Karlsruhe
>>> Handelsregister: Amtsgericht Mannheim - HRB 108550
>>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>>> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>>>
>>>
>>>
>>
>
>
--
Martin Krasser
blog: http://krasserm.blogspot.com
code: http://github.com/krasserm
twitter: http://twitter.com/mrt1nz
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Christian Schneider <ch...@die-schneider.net>.
If we agree that camel 3.0 aims to be compatible then the refactorings
are not prossible of course.
So I propose we try to agree on a future architecture for camel core and
also assign packages to the new architectural modules. Then we can go
for the low hanging fruits and keep the rest as it is.
Perhaps we could already use the new rules for classes we add so we
don´t make things worse for a later refactoring.
So let´s start with a discussion about the new architecture. Do we all
agree on the basic architecture I proposed or are there other proposals?
Thanks
Christian
Am 19.10.2010 06:23, schrieb Claus Ibsen:
> Hi
>
> I think the idea is really great, but I think the timing for this is
> *not* the right spot.
>
> And by saying that I mean the goal of Camel 3.0 is to have a short
> development cycle (not like 2.0 which took a long time).
> And as a minimum (IMHO):
> - To upgrade to JDK 1.6+,
> - Spring 3.0+,
> - To optimize the router internally,
> - And to switch to slf4j logger (*)
> - Keeping backwards compatibility as much as possible with 2.x is paramount
>
> Switching to slf4j instead of commons logging, allows us to use the
> MDC logging feature.
> This allows us to push information to the logs such as message id,
> transaction id etc. which can more easily correlate logs, not only
> with Camel alone, but also with other projects such as ActiveMQ, SMX
> etc.
>
>
> On top of that we now have many 3rd party projects which integrate out
> of the box with Camel, so changing the package structure in camel-core
> will break their integration. Which means they may not take up the
> effort to support both Camel 2.x/3.x.
>
> However I do think we should take the effort and pick up the low
> hanging fruits. I am sure there could be a couple of tangles which can
> be identified and fixed in Camel 3.0, without breaking backwards
> compatibility.
>
> I think doing this is something for Camel 4 or 5 or 6 (or whatever
> future version it may be) when or if we change to use Scala and use
> some other framework as foundation. There are cool stuff being
> developed for ActiveMQ 6 which are potential as a backbone for route
> messages. And it has a much better threading model which Camel can
> benefit as well.
>
> Anyway practical works beats theory, so setting up a branch in the
> sandbox to do experiments is a great idea.
>
> But its very important that we keep backwards compatibility with Camel
> 3.0. There are so many people started using Camel 2.x now so we should
> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
> 2.x but now on JDK 1.6 and with X other internal upgrades.
>
> Okay my first cup of coffee is ready, so beware this mail was written
> before I got "my first fix".
>
>
>
> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea<hz...@gmail.com> wrote:
>> I changed the thread name to [discuss].
>>
>> I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
>>
>> What I'd propose Christian is to add your proposal to the roadmap [1]. I will do the same for the dsl idea. There at least 2 ideas for dsl's built on top of the camel dsl (scheduling and debugging) that make me even more interested in coming up with a better solution.
>>
>> Once we get some traction on the main refactoring ideas I'd suggest starting one (or more) branches and start hacking, because there's not a whole lot of time left if we want to meet our target.
>>
>> Cheers,
>> Hadrian
>>
>> [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>>
>>
>>
>> On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>>
>>> Hi all,
>>>
>>> I will have some free time in december as I am changing my employer. So I am planning to work a little on some architectural improvements for camel 3.0.0. As these things are very critical to the stability of camel I would like to get feedback before I start any substantial work.
>>>
>>> As you surely know currently camel-core is quite tangled. So it is quite difficult where to start. Some time ago I proposed some improvements to simply reduce those dependency cycles. As I now know a lot more about camel I think that this simple aproach will not really work. So this time I want to do this a little more structured. So I start with two simple goals:
>>>
>>> "The camel components should know as little as possible about camel core"
>>>
>>> "The classes needed to setup camel should be separate from the things needed at run time"
>>>
>>> So why should this be important? Currently components depend on camel-core as a whole and there are no further rules which classes the components should use and which classes should be private to core. Even classes from the impl package are needed. So this means that any refactoring we do in camel core could affect all components. As camel is growing steadily this can become quite problematic.
>>>
>>> So my idea would be to split camel-core into three parts:
>>>
>>> api, builder, impl
>>>
>>> These should be structured in a way that these big building blocks do not have cyclic dependencies. Any other cycles can be ignored in this step.
>>>
>>> As allowed depdencies I propose ( "->" means may use, depends on):
>>>
>>> * -> api
>>> end user config -> builder
>>> builder -> impl
>>>
>>> I think the first thing we should do is to discuss and reach a consensus about a basic architecure and rules like above. Then the next step is to assign each package of core to one of the basic parts. Then the next step is to resolve cycles between the parts.
>>>
>>> What do you think about these ideas?
>>>
>>> Thanks
>>>
>>> Christian
>>>
>>> Christian Schneider
>>> Informationsverarbeitung
>>> Business Solutions
>>> Handel und Dispatching
>>>
>>> Tel : +49-(0)721-63-15482
>>>
>>> EnBW Systeme Infrastruktur Support GmbH
>>> Sitz der Gesellschaft: Karlsruhe
>>> Handelsregister: Amtsgericht Mannheim - HRB 108550
>>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>>> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>>>
>>>
>>>
>>
>
>
--
----
http://www.liquid-reality.de
Re: AW: [DISCUSS] Some thoughts about the architecture of camel
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 19 October 2010 8:22:11 am Schneider Christian wrote:
> +1 For having a 2.6 release like Dan proposed. As Claus said the new
> release should be as backwards compatible as possbile so I think it is not
> necessary to increase the major release. Q1 2011 could be a good date for
> this release.
I was actually thinking Dec for this if possible. I'm strongly considering
making 2.2.12 the last 2.2.x release for CXF that I do which would be
December. Need to present that to the CXF community, probably later today,
but in any case, getting folks off of 2.2.x sooner is quite important.
> +1 For doing the more advanced stuff like architecture of camel-core like I
> proposed in the 3.0 release. As the 2.6 release would have the short term
> stuff the release date could even be after Q1 2011 in my opinion.
Late Q1 or early Q2 or so. That's 5-6 months which would be a reasonable dev
effort for 3.0. IMO.
Dan
>
> Best Regards
>
> Christian
>
>
>
>
>
> Christian Schneider
> Informationsverarbeitung
> Business Solutions
> Handel und Dispatching
>
> Tel : +49-(0)721-63-15482
>
> EnBW Systeme Infrastruktur Support GmbH
> Sitz der Gesellschaft: Karlsruhe
> Handelsregister: Amtsgericht Mannheim HRB 108550
> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>
>
> -----Ursprüngliche Nachricht-----
> Von: Daniel Kulp [mailto:dkulp@apache.org]
> Gesendet: Dienstag, 19. Oktober 2010 13:47
> An: dev@camel.apache.org
> Cc: Claus Ibsen
> Betreff: Re: [DISCUSS] Some thoughts about the architecture of camel
>
> On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote:
> > Hi
> >
> > I think the idea is really great, but I think the timing for this is
> > *not* the right spot.
>
> Why not?
>
> > And by saying that I mean the goal of Camel 3.0 is to have a short
> > development cycle (not like 2.0 which took a long time).
> > And as a minimum (IMHO):
> > - To upgrade to JDK 1.6+,
> > - Spring 3.0+,
> > - To optimize the router internally,
> > - And to switch to slf4j logger (*)
> > - Keeping backwards compatibility as much as possible with 2.x is
> > paramount
>
> Umm.. Everything listed there could go into a 2.6 release. I don't see
> any reason for that to be what defines a 3.0 release.
>
> If we are going to have a 3.0, lets get the work done that would need to be
> done to provide a stable platform for the next year or so and provides the
> API's and feature that are requried for the various new and exciting ideas
> people are proposing.
>
> Dan
>
> > Switching to slf4j instead of commons logging, allows us to use the
> > MDC logging feature.
> > This allows us to push information to the logs such as message id,
> > transaction id etc. which can more easily correlate logs, not only
> > with Camel alone, but also with other projects such as ActiveMQ, SMX
> > etc.
> >
> >
> > On top of that we now have many 3rd party projects which integrate out
> > of the box with Camel, so changing the package structure in camel-core
> > will break their integration. Which means they may not take up the
> > effort to support both Camel 2.x/3.x.
> >
> > However I do think we should take the effort and pick up the low
> > hanging fruits. I am sure there could be a couple of tangles which can
> > be identified and fixed in Camel 3.0, without breaking backwards
> > compatibility.
> >
> > I think doing this is something for Camel 4 or 5 or 6 (or whatever
> > future version it may be) when or if we change to use Scala and use
> > some other framework as foundation. There are cool stuff being
> > developed for ActiveMQ 6 which are potential as a backbone for route
> > messages. And it has a much better threading model which Camel can
> > benefit as well.
> >
> > Anyway practical works beats theory, so setting up a branch in the
> > sandbox to do experiments is a great idea.
> >
> > But its very important that we keep backwards compatibility with Camel
> > 3.0. There are so many people started using Camel 2.x now so we should
> > keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
> > 2.x but now on JDK 1.6 and with X other internal upgrades.
> >
> > Okay my first cup of coffee is ready, so beware this mail was written
> > before I got "my first fix".
> >
> > On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com>
wrote:
> > > I changed the thread name to [discuss].
> > >
> > > I like that idea and it's something we contemplated in the past. This
> > > will bring back the idea of getting the dsl out of core as well.
> > >
> > > What I'd propose Christian is to add your proposal to the roadmap [1].
> > > I will do the same for the dsl idea. There at least 2 ideas for dsl's
> > > built on top of the camel dsl (scheduling and debugging) that make me
> > > even more interested in coming up with a better solution.
> > >
> > > Once we get some traction on the main refactoring ideas I'd suggest
> > > starting one (or more) branches and start hacking, because there's not
> > > a whole lot of time left if we want to meet our target.
> > >
> > > Cheers,
> > > Hadrian
> > >
> > > [1]
> > > https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
> > >
> > > On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
> > >> Hi all,
> > >>
> > >> I will have some free time in december as I am changing my employer.
> > >> So I am planning to work a little on some architectural improvements
> > >> for camel 3.0.0. As these things are very critical to the stability
> > >> of camel I would like to get feedback before I start any substantial
> > >> work.
> > >>
> > >> As you surely know currently camel-core is quite tangled. So it is
> > >> quite difficult where to start. Some time ago I proposed some
> > >> improvements to simply reduce those dependency cycles. As I now know
> > >> a lot more about camel I think that this simple aproach will not
> > >> really work. So this time I want to do this a little more structured.
> > >> So I start with two simple goals:
> > >>
> > >> "The camel components should know as little as possible about camel
> > >> core"
> > >>
> > >> "The classes needed to setup camel should be separate from the things
> > >> needed at run time"
> > >>
> > >> So why should this be important? Currently components depend on
> > >> camel-core as a whole and there are no further rules which classes the
> > >> components should use and which classes should be private to core.
> > >> Even classes from the impl package are needed. So this means that any
> > >> refactoring we do in camel core could affect all components. As camel
> > >> is growing steadily this can become quite problematic.
> > >>
> > >> So my idea would be to split camel-core into three parts:
> > >>
> > >> api, builder, impl
> > >>
> > >> These should be structured in a way that these big building blocks do
> > >> not have cyclic dependencies. Any other cycles can be ignored in this
> > >> step.
> > >>
> > >> As allowed depdencies I propose ( "->" means may use, depends on):
> > >>
> > >> * -> api
> > >> end user config -> builder
> > >> builder -> impl
> > >>
> > >> I think the first thing we should do is to discuss and reach a
> > >> consensus about a basic architecure and rules like above. Then the
> > >> next step is to assign each package of core to one of the basic
> > >> parts. Then the next step is to resolve cycles between the parts.
> > >>
> > >> What do you think about these ideas?
> > >>
> > >> Thanks
> > >>
> > >> Christian
> > >>
> > >> Christian Schneider
> > >> Informationsverarbeitung
> > >> Business Solutions
> > >> Handel und Dispatching
> > >>
> > >> Tel : +49-(0)721-63-15482
> > >>
> > >> EnBW Systeme Infrastruktur Support GmbH
> > >> Sitz der Gesellschaft: Karlsruhe
> > >> Handelsregister: Amtsgericht Mannheim - HRB 108550
> > >> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
> > >> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by James Strachan <ja...@gmail.com>.
Changing Camel to 3.x matches the Spring naming conventions sounds a
good enough idea in itself; but adding in the JDK 5->6 change too,
then 3.0 sounds like a no brainer to me.
Then Camel 2.x works with Spring 2.x and Camel 3.x works with Spring
3.x; nice and easy to remember.
If folks want to experiment with a non-backwards compatible 4.x
version of Camel we can always have parallel experimental branches
where folks can play; as progress is made we can weigh up the
strengths and weaknesses of the different refactorings folks
experiment with.
On 19 October 2010 13:26, Schneider Christian
<Ch...@enbw.com> wrote:
> If you consider spring and jdk a (somewhat) breaking change then a 3.0 version is the right thing of course. I don´t care too much if this version is called 2.6 or 3.0 ;-)
>
> In this case I would like to have the more advanced stuff in the 4.0 version. Do you think that is possible?
>
> Best Regards
>
> Christian
>
>
> Christian Schneider
> Informationsverarbeitung
> Business Solutions
> Handel und Dispatching
>
> Tel : +49-(0)721-63-15482
>
> EnBW Systeme Infrastruktur Support GmbH
> Sitz der Gesellschaft: Karlsruhe
> Handelsregister: Amtsgericht Mannheim HRB 108550
> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>
>
> -----Ursprüngliche Nachricht-----
> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
> Gesendet: Dienstag, 19. Oktober 2010 14:22
> An: dev@camel.apache.org
> Betreff: Re: [DISCUSS] Some thoughts about the architecture of camel
>
> On Tue, Oct 19, 2010 at 1:47 PM, Daniel Kulp <dk...@apache.org> wrote:
>> On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote:
>>> Hi
>>>
>>> I think the idea is really great, but I think the timing for this is
>>> *not* the right spot.
>>
>>
>> Why not?
>>
>>>
>>> And by saying that I mean the goal of Camel 3.0 is to have a short
>>> development cycle (not like 2.0 which took a long time).
>>> And as a minimum (IMHO):
>>> - To upgrade to JDK 1.6+,
>>> - Spring 3.0+,
>>> - To optimize the router internally,
>>> - And to switch to slf4j logger (*)
>>> - Keeping backwards compatibility as much as possible with 2.x is paramount
>>
>> Umm.. Everything listed there could go into a 2.6 release. I don't see any
>> reason for that to be what defines a 3.0 release.
>>
>
> Sorry but those changes are major. Changing the minimum supported JDK
> platform is.
> eg Spring 2.5 still supports JDK 1.4. Only Spring 3.0 is JDK 1.5+ only.
>
> We can't just change that mid stream.
>
> And we dont du usually do so many minor releases as you do with CXF,
> eg 2.2.1 -> 2.2.11
> At Camel we do 2.0, 2.1, 2.2, 2.3 etc.
>
>
>> If we are going to have a 3.0, lets get the work done that would need to be
>> done to provide a stable platform for the next year or so and provides the
>> API's and feature that are requried for the various new and exciting ideas
>> people are proposing.
>>
>
> Sorry but I think the community want an easy upgrade path for JDK 1.6
> / Spring 3.0 based on the current 2.x architecture.
>
> It works really well, easy to write custom components. Hence why we
> got so many now.
> And many 3rd party projects have integrated out of the box with Camel.
> And we would lose some if we keep changing the architecture.
>
> We should not do a "Tapestry" with the Camel project, and change the
> core at each major release.
>
>
>> Dan
>>
>>
>>> Switching to slf4j instead of commons logging, allows us to use the
>>> MDC logging feature.
>>> This allows us to push information to the logs such as message id,
>>> transaction id etc. which can more easily correlate logs, not only
>>> with Camel alone, but also with other projects such as ActiveMQ, SMX
>>> etc.
>>>
>>>
>>> On top of that we now have many 3rd party projects which integrate out
>>> of the box with Camel, so changing the package structure in camel-core
>>> will break their integration. Which means they may not take up the
>>> effort to support both Camel 2.x/3.x.
>>>
>>> However I do think we should take the effort and pick up the low
>>> hanging fruits. I am sure there could be a couple of tangles which can
>>> be identified and fixed in Camel 3.0, without breaking backwards
>>> compatibility.
>>>
>>> I think doing this is something for Camel 4 or 5 or 6 (or whatever
>>> future version it may be) when or if we change to use Scala and use
>>> some other framework as foundation. There are cool stuff being
>>> developed for ActiveMQ 6 which are potential as a backbone for route
>>> messages. And it has a much better threading model which Camel can
>>> benefit as well.
>>>
>>> Anyway practical works beats theory, so setting up a branch in the
>>> sandbox to do experiments is a great idea.
>>>
>>> But its very important that we keep backwards compatibility with Camel
>>> 3.0. There are so many people started using Camel 2.x now so we should
>>> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
>>> 2.x but now on JDK 1.6 and with X other internal upgrades.
>>>
>>> Okay my first cup of coffee is ready, so beware this mail was written
>>> before I got "my first fix".
>>>
>>> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>> > I changed the thread name to [discuss].
>>> >
>>> > I like that idea and it's something we contemplated in the past. This
>>> > will bring back the idea of getting the dsl out of core as well.
>>> >
>>> > What I'd propose Christian is to add your proposal to the roadmap [1]. I
>>> > will do the same for the dsl idea. There at least 2 ideas for dsl's
>>> > built on top of the camel dsl (scheduling and debugging) that make me
>>> > even more interested in coming up with a better solution.
>>> >
>>> > Once we get some traction on the main refactoring ideas I'd suggest
>>> > starting one (or more) branches and start hacking, because there's not a
>>> > whole lot of time left if we want to meet our target.
>>> >
>>> > Cheers,
>>> > Hadrian
>>> >
>>> > [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>>> >
>>> > On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>>> >> Hi all,
>>> >>
>>> >> I will have some free time in december as I am changing my employer. So
>>> >> I am planning to work a little on some architectural improvements for
>>> >> camel 3.0.0. As these things are very critical to the stability of
>>> >> camel I would like to get feedback before I start any substantial work.
>>> >>
>>> >> As you surely know currently camel-core is quite tangled. So it is quite
>>> >> difficult where to start. Some time ago I proposed some improvements to
>>> >> simply reduce those dependency cycles. As I now know a lot more about
>>> >> camel I think that this simple aproach will not really work. So this
>>> >> time I want to do this a little more structured. So I start with two
>>> >> simple goals:
>>> >>
>>> >> "The camel components should know as little as possible about camel
>>> >> core"
>>> >>
>>> >> "The classes needed to setup camel should be separate from the things
>>> >> needed at run time"
>>> >>
>>> >> So why should this be important? Currently components depend on
>>> >> camel-core as a whole and there are no further rules which classes the
>>> >> components should use and which classes should be private to core. Even
>>> >> classes from the impl package are needed. So this means that any
>>> >> refactoring we do in camel core could affect all components. As camel
>>> >> is growing steadily this can become quite problematic.
>>> >>
>>> >> So my idea would be to split camel-core into three parts:
>>> >>
>>> >> api, builder, impl
>>> >>
>>> >> These should be structured in a way that these big building blocks do
>>> >> not have cyclic dependencies. Any other cycles can be ignored in this
>>> >> step.
>>> >>
>>> >> As allowed depdencies I propose ( "->" means may use, depends on):
>>> >>
>>> >> * -> api
>>> >> end user config -> builder
>>> >> builder -> impl
>>> >>
>>> >> I think the first thing we should do is to discuss and reach a consensus
>>> >> about a basic architecure and rules like above. Then the next step is
>>> >> to assign each package of core to one of the basic parts. Then the next
>>> >> step is to resolve cycles between the parts.
>>> >>
>>> >> What do you think about these ideas?
>>> >>
>>> >> Thanks
>>> >>
>>> >> Christian
>>> >>
>>> >> Christian Schneider
>>> >> Informationsverarbeitung
>>> >> Business Solutions
>>> >> Handel und Dispatching
>>> >>
>>> >> Tel : +49-(0)721-63-15482
>>> >>
>>> >> EnBW Systeme Infrastruktur Support GmbH
>>> >> Sitz der Gesellschaft: Karlsruhe
>>> >> Handelsregister: Amtsgericht Mannheim - HRB 108550
>>> >> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>>> >> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Oct 19, 2010 at 2:26 PM, Schneider Christian
<Ch...@enbw.com> wrote:
> If you consider spring and jdk a (somewhat) breaking change then a 3.0 version is the right thing of course. I don´t care too much if this version is called 2.6 or 3.0 ;-)
>
> In this case I would like to have the more advanced stuff in the 4.0 version. Do you think that is possible?
>
Yeah definitely. We all know that at some time the current
architecture needs change and a new major version such as 4.0 is a
good version to do that. Then we also have longer time to work on it,
and people on the current 2.x/3.x architecture can rest assured the
API stays compatible so their components and other 3rd party projects
integrating out of the box with Camel, still works as is.
And maybe at Camel 4, we got goodies from JDK7 we can leverage (NIO2,
ForkJoin) or there are some great other frameworks out there we can
let Camel depend upon.
Or maybe even the Scala stuff just good so compelling that we all got
hooked and rewrote camel-core in Scala.
> Best Regards
>
> Christian
>
>
> Christian Schneider
> Informationsverarbeitung
> Business Solutions
> Handel und Dispatching
>
> Tel : +49-(0)721-63-15482
>
> EnBW Systeme Infrastruktur Support GmbH
> Sitz der Gesellschaft: Karlsruhe
> Handelsregister: Amtsgericht Mannheim HRB 108550
> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>
>
> -----Ursprüngliche Nachricht-----
> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
> Gesendet: Dienstag, 19. Oktober 2010 14:22
> An: dev@camel.apache.org
> Betreff: Re: [DISCUSS] Some thoughts about the architecture of camel
>
> On Tue, Oct 19, 2010 at 1:47 PM, Daniel Kulp <dk...@apache.org> wrote:
>> On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote:
>>> Hi
>>>
>>> I think the idea is really great, but I think the timing for this is
>>> *not* the right spot.
>>
>>
>> Why not?
>>
>>>
>>> And by saying that I mean the goal of Camel 3.0 is to have a short
>>> development cycle (not like 2.0 which took a long time).
>>> And as a minimum (IMHO):
>>> - To upgrade to JDK 1.6+,
>>> - Spring 3.0+,
>>> - To optimize the router internally,
>>> - And to switch to slf4j logger (*)
>>> - Keeping backwards compatibility as much as possible with 2.x is paramount
>>
>> Umm.. Everything listed there could go into a 2.6 release. I don't see any
>> reason for that to be what defines a 3.0 release.
>>
>
> Sorry but those changes are major. Changing the minimum supported JDK
> platform is.
> eg Spring 2.5 still supports JDK 1.4. Only Spring 3.0 is JDK 1.5+ only.
>
> We can't just change that mid stream.
>
> And we dont du usually do so many minor releases as you do with CXF,
> eg 2.2.1 -> 2.2.11
> At Camel we do 2.0, 2.1, 2.2, 2.3 etc.
>
>
>> If we are going to have a 3.0, lets get the work done that would need to be
>> done to provide a stable platform for the next year or so and provides the
>> API's and feature that are requried for the various new and exciting ideas
>> people are proposing.
>>
>
> Sorry but I think the community want an easy upgrade path for JDK 1.6
> / Spring 3.0 based on the current 2.x architecture.
>
> It works really well, easy to write custom components. Hence why we
> got so many now.
> And many 3rd party projects have integrated out of the box with Camel.
> And we would lose some if we keep changing the architecture.
>
> We should not do a "Tapestry" with the Camel project, and change the
> core at each major release.
>
>
>> Dan
>>
>>
>>> Switching to slf4j instead of commons logging, allows us to use the
>>> MDC logging feature.
>>> This allows us to push information to the logs such as message id,
>>> transaction id etc. which can more easily correlate logs, not only
>>> with Camel alone, but also with other projects such as ActiveMQ, SMX
>>> etc.
>>>
>>>
>>> On top of that we now have many 3rd party projects which integrate out
>>> of the box with Camel, so changing the package structure in camel-core
>>> will break their integration. Which means they may not take up the
>>> effort to support both Camel 2.x/3.x.
>>>
>>> However I do think we should take the effort and pick up the low
>>> hanging fruits. I am sure there could be a couple of tangles which can
>>> be identified and fixed in Camel 3.0, without breaking backwards
>>> compatibility.
>>>
>>> I think doing this is something for Camel 4 or 5 or 6 (or whatever
>>> future version it may be) when or if we change to use Scala and use
>>> some other framework as foundation. There are cool stuff being
>>> developed for ActiveMQ 6 which are potential as a backbone for route
>>> messages. And it has a much better threading model which Camel can
>>> benefit as well.
>>>
>>> Anyway practical works beats theory, so setting up a branch in the
>>> sandbox to do experiments is a great idea.
>>>
>>> But its very important that we keep backwards compatibility with Camel
>>> 3.0. There are so many people started using Camel 2.x now so we should
>>> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
>>> 2.x but now on JDK 1.6 and with X other internal upgrades.
>>>
>>> Okay my first cup of coffee is ready, so beware this mail was written
>>> before I got "my first fix".
>>>
>>> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>> > I changed the thread name to [discuss].
>>> >
>>> > I like that idea and it's something we contemplated in the past. This
>>> > will bring back the idea of getting the dsl out of core as well.
>>> >
>>> > What I'd propose Christian is to add your proposal to the roadmap [1]. I
>>> > will do the same for the dsl idea. There at least 2 ideas for dsl's
>>> > built on top of the camel dsl (scheduling and debugging) that make me
>>> > even more interested in coming up with a better solution.
>>> >
>>> > Once we get some traction on the main refactoring ideas I'd suggest
>>> > starting one (or more) branches and start hacking, because there's not a
>>> > whole lot of time left if we want to meet our target.
>>> >
>>> > Cheers,
>>> > Hadrian
>>> >
>>> > [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>>> >
>>> > On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>>> >> Hi all,
>>> >>
>>> >> I will have some free time in december as I am changing my employer. So
>>> >> I am planning to work a little on some architectural improvements for
>>> >> camel 3.0.0. As these things are very critical to the stability of
>>> >> camel I would like to get feedback before I start any substantial work.
>>> >>
>>> >> As you surely know currently camel-core is quite tangled. So it is quite
>>> >> difficult where to start. Some time ago I proposed some improvements to
>>> >> simply reduce those dependency cycles. As I now know a lot more about
>>> >> camel I think that this simple aproach will not really work. So this
>>> >> time I want to do this a little more structured. So I start with two
>>> >> simple goals:
>>> >>
>>> >> "The camel components should know as little as possible about camel
>>> >> core"
>>> >>
>>> >> "The classes needed to setup camel should be separate from the things
>>> >> needed at run time"
>>> >>
>>> >> So why should this be important? Currently components depend on
>>> >> camel-core as a whole and there are no further rules which classes the
>>> >> components should use and which classes should be private to core. Even
>>> >> classes from the impl package are needed. So this means that any
>>> >> refactoring we do in camel core could affect all components. As camel
>>> >> is growing steadily this can become quite problematic.
>>> >>
>>> >> So my idea would be to split camel-core into three parts:
>>> >>
>>> >> api, builder, impl
>>> >>
>>> >> These should be structured in a way that these big building blocks do
>>> >> not have cyclic dependencies. Any other cycles can be ignored in this
>>> >> step.
>>> >>
>>> >> As allowed depdencies I propose ( "->" means may use, depends on):
>>> >>
>>> >> * -> api
>>> >> end user config -> builder
>>> >> builder -> impl
>>> >>
>>> >> I think the first thing we should do is to discuss and reach a consensus
>>> >> about a basic architecure and rules like above. Then the next step is
>>> >> to assign each package of core to one of the basic parts. Then the next
>>> >> step is to resolve cycles between the parts.
>>> >>
>>> >> What do you think about these ideas?
>>> >>
>>> >> Thanks
>>> >>
>>> >> Christian
>>> >>
>>> >> Christian Schneider
>>> >> Informationsverarbeitung
>>> >> Business Solutions
>>> >> Handel und Dispatching
>>> >>
>>> >> Tel : +49-(0)721-63-15482
>>> >>
>>> >> EnBW Systeme Infrastruktur Support GmbH
>>> >> Sitz der Gesellschaft: Karlsruhe
>>> >> Handelsregister: Amtsgericht Mannheim - HRB 108550
>>> >> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>>> >> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
AW: [DISCUSS] Some thoughts about the architecture of camel
Posted by Schneider Christian <Ch...@enbw.com>.
If you consider spring and jdk a (somewhat) breaking change then a 3.0 version is the right thing of course. I don´t care too much if this version is called 2.6 or 3.0 ;-)
In this case I would like to have the more advanced stuff in the 4.0 version. Do you think that is possible?
Best Regards
Christian
Christian Schneider
Informationsverarbeitung
Business Solutions
Handel und Dispatching
Tel : +49-(0)721-63-15482
EnBW Systeme Infrastruktur Support GmbH
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim HRB 108550
Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
Geschäftsführer: Jochen Adenau, Hans-Günther Meier
-----Ursprüngliche Nachricht-----
Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
Gesendet: Dienstag, 19. Oktober 2010 14:22
An: dev@camel.apache.org
Betreff: Re: [DISCUSS] Some thoughts about the architecture of camel
On Tue, Oct 19, 2010 at 1:47 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote:
>> Hi
>>
>> I think the idea is really great, but I think the timing for this is
>> *not* the right spot.
>
>
> Why not?
>
>>
>> And by saying that I mean the goal of Camel 3.0 is to have a short
>> development cycle (not like 2.0 which took a long time).
>> And as a minimum (IMHO):
>> - To upgrade to JDK 1.6+,
>> - Spring 3.0+,
>> - To optimize the router internally,
>> - And to switch to slf4j logger (*)
>> - Keeping backwards compatibility as much as possible with 2.x is paramount
>
> Umm.. Everything listed there could go into a 2.6 release. I don't see any
> reason for that to be what defines a 3.0 release.
>
Sorry but those changes are major. Changing the minimum supported JDK
platform is.
eg Spring 2.5 still supports JDK 1.4. Only Spring 3.0 is JDK 1.5+ only.
We can't just change that mid stream.
And we dont du usually do so many minor releases as you do with CXF,
eg 2.2.1 -> 2.2.11
At Camel we do 2.0, 2.1, 2.2, 2.3 etc.
> If we are going to have a 3.0, lets get the work done that would need to be
> done to provide a stable platform for the next year or so and provides the
> API's and feature that are requried for the various new and exciting ideas
> people are proposing.
>
Sorry but I think the community want an easy upgrade path for JDK 1.6
/ Spring 3.0 based on the current 2.x architecture.
It works really well, easy to write custom components. Hence why we
got so many now.
And many 3rd party projects have integrated out of the box with Camel.
And we would lose some if we keep changing the architecture.
We should not do a "Tapestry" with the Camel project, and change the
core at each major release.
> Dan
>
>
>> Switching to slf4j instead of commons logging, allows us to use the
>> MDC logging feature.
>> This allows us to push information to the logs such as message id,
>> transaction id etc. which can more easily correlate logs, not only
>> with Camel alone, but also with other projects such as ActiveMQ, SMX
>> etc.
>>
>>
>> On top of that we now have many 3rd party projects which integrate out
>> of the box with Camel, so changing the package structure in camel-core
>> will break their integration. Which means they may not take up the
>> effort to support both Camel 2.x/3.x.
>>
>> However I do think we should take the effort and pick up the low
>> hanging fruits. I am sure there could be a couple of tangles which can
>> be identified and fixed in Camel 3.0, without breaking backwards
>> compatibility.
>>
>> I think doing this is something for Camel 4 or 5 or 6 (or whatever
>> future version it may be) when or if we change to use Scala and use
>> some other framework as foundation. There are cool stuff being
>> developed for ActiveMQ 6 which are potential as a backbone for route
>> messages. And it has a much better threading model which Camel can
>> benefit as well.
>>
>> Anyway practical works beats theory, so setting up a branch in the
>> sandbox to do experiments is a great idea.
>>
>> But its very important that we keep backwards compatibility with Camel
>> 3.0. There are so many people started using Camel 2.x now so we should
>> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
>> 2.x but now on JDK 1.6 and with X other internal upgrades.
>>
>> Okay my first cup of coffee is ready, so beware this mail was written
>> before I got "my first fix".
>>
>> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> > I changed the thread name to [discuss].
>> >
>> > I like that idea and it's something we contemplated in the past. This
>> > will bring back the idea of getting the dsl out of core as well.
>> >
>> > What I'd propose Christian is to add your proposal to the roadmap [1]. I
>> > will do the same for the dsl idea. There at least 2 ideas for dsl's
>> > built on top of the camel dsl (scheduling and debugging) that make me
>> > even more interested in coming up with a better solution.
>> >
>> > Once we get some traction on the main refactoring ideas I'd suggest
>> > starting one (or more) branches and start hacking, because there's not a
>> > whole lot of time left if we want to meet our target.
>> >
>> > Cheers,
>> > Hadrian
>> >
>> > [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>> >
>> > On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>> >> Hi all,
>> >>
>> >> I will have some free time in december as I am changing my employer. So
>> >> I am planning to work a little on some architectural improvements for
>> >> camel 3.0.0. As these things are very critical to the stability of
>> >> camel I would like to get feedback before I start any substantial work.
>> >>
>> >> As you surely know currently camel-core is quite tangled. So it is quite
>> >> difficult where to start. Some time ago I proposed some improvements to
>> >> simply reduce those dependency cycles. As I now know a lot more about
>> >> camel I think that this simple aproach will not really work. So this
>> >> time I want to do this a little more structured. So I start with two
>> >> simple goals:
>> >>
>> >> "The camel components should know as little as possible about camel
>> >> core"
>> >>
>> >> "The classes needed to setup camel should be separate from the things
>> >> needed at run time"
>> >>
>> >> So why should this be important? Currently components depend on
>> >> camel-core as a whole and there are no further rules which classes the
>> >> components should use and which classes should be private to core. Even
>> >> classes from the impl package are needed. So this means that any
>> >> refactoring we do in camel core could affect all components. As camel
>> >> is growing steadily this can become quite problematic.
>> >>
>> >> So my idea would be to split camel-core into three parts:
>> >>
>> >> api, builder, impl
>> >>
>> >> These should be structured in a way that these big building blocks do
>> >> not have cyclic dependencies. Any other cycles can be ignored in this
>> >> step.
>> >>
>> >> As allowed depdencies I propose ( "->" means may use, depends on):
>> >>
>> >> * -> api
>> >> end user config -> builder
>> >> builder -> impl
>> >>
>> >> I think the first thing we should do is to discuss and reach a consensus
>> >> about a basic architecure and rules like above. Then the next step is
>> >> to assign each package of core to one of the basic parts. Then the next
>> >> step is to resolve cycles between the parts.
>> >>
>> >> What do you think about these ideas?
>> >>
>> >> Thanks
>> >>
>> >> Christian
>> >>
>> >> Christian Schneider
>> >> Informationsverarbeitung
>> >> Business Solutions
>> >> Handel und Dispatching
>> >>
>> >> Tel : +49-(0)721-63-15482
>> >>
>> >> EnBW Systeme Infrastruktur Support GmbH
>> >> Sitz der Gesellschaft: Karlsruhe
>> >> Handelsregister: Amtsgericht Mannheim - HRB 108550
>> >> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>> >> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Oct 19, 2010 at 1:47 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote:
>> Hi
>>
>> I think the idea is really great, but I think the timing for this is
>> *not* the right spot.
>
>
> Why not?
>
>>
>> And by saying that I mean the goal of Camel 3.0 is to have a short
>> development cycle (not like 2.0 which took a long time).
>> And as a minimum (IMHO):
>> - To upgrade to JDK 1.6+,
>> - Spring 3.0+,
>> - To optimize the router internally,
>> - And to switch to slf4j logger (*)
>> - Keeping backwards compatibility as much as possible with 2.x is paramount
>
> Umm.. Everything listed there could go into a 2.6 release. I don't see any
> reason for that to be what defines a 3.0 release.
>
Sorry but those changes are major. Changing the minimum supported JDK
platform is.
eg Spring 2.5 still supports JDK 1.4. Only Spring 3.0 is JDK 1.5+ only.
We can't just change that mid stream.
And we dont du usually do so many minor releases as you do with CXF,
eg 2.2.1 -> 2.2.11
At Camel we do 2.0, 2.1, 2.2, 2.3 etc.
> If we are going to have a 3.0, lets get the work done that would need to be
> done to provide a stable platform for the next year or so and provides the
> API's and feature that are requried for the various new and exciting ideas
> people are proposing.
>
Sorry but I think the community want an easy upgrade path for JDK 1.6
/ Spring 3.0 based on the current 2.x architecture.
It works really well, easy to write custom components. Hence why we
got so many now.
And many 3rd party projects have integrated out of the box with Camel.
And we would lose some if we keep changing the architecture.
We should not do a "Tapestry" with the Camel project, and change the
core at each major release.
> Dan
>
>
>> Switching to slf4j instead of commons logging, allows us to use the
>> MDC logging feature.
>> This allows us to push information to the logs such as message id,
>> transaction id etc. which can more easily correlate logs, not only
>> with Camel alone, but also with other projects such as ActiveMQ, SMX
>> etc.
>>
>>
>> On top of that we now have many 3rd party projects which integrate out
>> of the box with Camel, so changing the package structure in camel-core
>> will break their integration. Which means they may not take up the
>> effort to support both Camel 2.x/3.x.
>>
>> However I do think we should take the effort and pick up the low
>> hanging fruits. I am sure there could be a couple of tangles which can
>> be identified and fixed in Camel 3.0, without breaking backwards
>> compatibility.
>>
>> I think doing this is something for Camel 4 or 5 or 6 (or whatever
>> future version it may be) when or if we change to use Scala and use
>> some other framework as foundation. There are cool stuff being
>> developed for ActiveMQ 6 which are potential as a backbone for route
>> messages. And it has a much better threading model which Camel can
>> benefit as well.
>>
>> Anyway practical works beats theory, so setting up a branch in the
>> sandbox to do experiments is a great idea.
>>
>> But its very important that we keep backwards compatibility with Camel
>> 3.0. There are so many people started using Camel 2.x now so we should
>> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
>> 2.x but now on JDK 1.6 and with X other internal upgrades.
>>
>> Okay my first cup of coffee is ready, so beware this mail was written
>> before I got "my first fix".
>>
>> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> > I changed the thread name to [discuss].
>> >
>> > I like that idea and it's something we contemplated in the past. This
>> > will bring back the idea of getting the dsl out of core as well.
>> >
>> > What I'd propose Christian is to add your proposal to the roadmap [1]. I
>> > will do the same for the dsl idea. There at least 2 ideas for dsl's
>> > built on top of the camel dsl (scheduling and debugging) that make me
>> > even more interested in coming up with a better solution.
>> >
>> > Once we get some traction on the main refactoring ideas I'd suggest
>> > starting one (or more) branches and start hacking, because there's not a
>> > whole lot of time left if we want to meet our target.
>> >
>> > Cheers,
>> > Hadrian
>> >
>> > [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>> >
>> > On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>> >> Hi all,
>> >>
>> >> I will have some free time in december as I am changing my employer. So
>> >> I am planning to work a little on some architectural improvements for
>> >> camel 3.0.0. As these things are very critical to the stability of
>> >> camel I would like to get feedback before I start any substantial work.
>> >>
>> >> As you surely know currently camel-core is quite tangled. So it is quite
>> >> difficult where to start. Some time ago I proposed some improvements to
>> >> simply reduce those dependency cycles. As I now know a lot more about
>> >> camel I think that this simple aproach will not really work. So this
>> >> time I want to do this a little more structured. So I start with two
>> >> simple goals:
>> >>
>> >> "The camel components should know as little as possible about camel
>> >> core"
>> >>
>> >> "The classes needed to setup camel should be separate from the things
>> >> needed at run time"
>> >>
>> >> So why should this be important? Currently components depend on
>> >> camel-core as a whole and there are no further rules which classes the
>> >> components should use and which classes should be private to core. Even
>> >> classes from the impl package are needed. So this means that any
>> >> refactoring we do in camel core could affect all components. As camel
>> >> is growing steadily this can become quite problematic.
>> >>
>> >> So my idea would be to split camel-core into three parts:
>> >>
>> >> api, builder, impl
>> >>
>> >> These should be structured in a way that these big building blocks do
>> >> not have cyclic dependencies. Any other cycles can be ignored in this
>> >> step.
>> >>
>> >> As allowed depdencies I propose ( "->" means may use, depends on):
>> >>
>> >> * -> api
>> >> end user config -> builder
>> >> builder -> impl
>> >>
>> >> I think the first thing we should do is to discuss and reach a consensus
>> >> about a basic architecure and rules like above. Then the next step is
>> >> to assign each package of core to one of the basic parts. Then the next
>> >> step is to resolve cycles between the parts.
>> >>
>> >> What do you think about these ideas?
>> >>
>> >> Thanks
>> >>
>> >> Christian
>> >>
>> >> Christian Schneider
>> >> Informationsverarbeitung
>> >> Business Solutions
>> >> Handel und Dispatching
>> >>
>> >> Tel : +49-(0)721-63-15482
>> >>
>> >> EnBW Systeme Infrastruktur Support GmbH
>> >> Sitz der Gesellschaft: Karlsruhe
>> >> Handelsregister: Amtsgericht Mannheim - HRB 108550
>> >> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>> >> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
AW: [DISCUSS] Some thoughts about the architecture of camel
Posted by Schneider Christian <Ch...@enbw.com>.
+1 For having a 2.6 release like Dan proposed. As Claus said the new release should be as backwards compatible as possbile so I think it is not necessary to increase the major release. Q1 2011 could be a good date for this release.
+1 For doing the more advanced stuff like architecture of camel-core like I proposed in the 3.0 release. As the 2.6 release would have the short term stuff the release date could even be after Q1 2011 in my opinion.
Best Regards
Christian
Christian Schneider
Informationsverarbeitung
Business Solutions
Handel und Dispatching
Tel : +49-(0)721-63-15482
EnBW Systeme Infrastruktur Support GmbH
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim HRB 108550
Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
Geschäftsführer: Jochen Adenau, Hans-Günther Meier
-----Ursprüngliche Nachricht-----
Von: Daniel Kulp [mailto:dkulp@apache.org]
Gesendet: Dienstag, 19. Oktober 2010 13:47
An: dev@camel.apache.org
Cc: Claus Ibsen
Betreff: Re: [DISCUSS] Some thoughts about the architecture of camel
On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote:
> Hi
>
> I think the idea is really great, but I think the timing for this is
> *not* the right spot.
Why not?
>
> And by saying that I mean the goal of Camel 3.0 is to have a short
> development cycle (not like 2.0 which took a long time).
> And as a minimum (IMHO):
> - To upgrade to JDK 1.6+,
> - Spring 3.0+,
> - To optimize the router internally,
> - And to switch to slf4j logger (*)
> - Keeping backwards compatibility as much as possible with 2.x is paramount
Umm.. Everything listed there could go into a 2.6 release. I don't see any
reason for that to be what defines a 3.0 release.
If we are going to have a 3.0, lets get the work done that would need to be
done to provide a stable platform for the next year or so and provides the
API's and feature that are requried for the various new and exciting ideas
people are proposing.
Dan
> Switching to slf4j instead of commons logging, allows us to use the
> MDC logging feature.
> This allows us to push information to the logs such as message id,
> transaction id etc. which can more easily correlate logs, not only
> with Camel alone, but also with other projects such as ActiveMQ, SMX
> etc.
>
>
> On top of that we now have many 3rd party projects which integrate out
> of the box with Camel, so changing the package structure in camel-core
> will break their integration. Which means they may not take up the
> effort to support both Camel 2.x/3.x.
>
> However I do think we should take the effort and pick up the low
> hanging fruits. I am sure there could be a couple of tangles which can
> be identified and fixed in Camel 3.0, without breaking backwards
> compatibility.
>
> I think doing this is something for Camel 4 or 5 or 6 (or whatever
> future version it may be) when or if we change to use Scala and use
> some other framework as foundation. There are cool stuff being
> developed for ActiveMQ 6 which are potential as a backbone for route
> messages. And it has a much better threading model which Camel can
> benefit as well.
>
> Anyway practical works beats theory, so setting up a branch in the
> sandbox to do experiments is a great idea.
>
> But its very important that we keep backwards compatibility with Camel
> 3.0. There are so many people started using Camel 2.x now so we should
> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
> 2.x but now on JDK 1.6 and with X other internal upgrades.
>
> Okay my first cup of coffee is ready, so beware this mail was written
> before I got "my first fix".
>
> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> > I changed the thread name to [discuss].
> >
> > I like that idea and it's something we contemplated in the past. This
> > will bring back the idea of getting the dsl out of core as well.
> >
> > What I'd propose Christian is to add your proposal to the roadmap [1]. I
> > will do the same for the dsl idea. There at least 2 ideas for dsl's
> > built on top of the camel dsl (scheduling and debugging) that make me
> > even more interested in coming up with a better solution.
> >
> > Once we get some traction on the main refactoring ideas I'd suggest
> > starting one (or more) branches and start hacking, because there's not a
> > whole lot of time left if we want to meet our target.
> >
> > Cheers,
> > Hadrian
> >
> > [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
> >
> > On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
> >> Hi all,
> >>
> >> I will have some free time in december as I am changing my employer. So
> >> I am planning to work a little on some architectural improvements for
> >> camel 3.0.0. As these things are very critical to the stability of
> >> camel I would like to get feedback before I start any substantial work.
> >>
> >> As you surely know currently camel-core is quite tangled. So it is quite
> >> difficult where to start. Some time ago I proposed some improvements to
> >> simply reduce those dependency cycles. As I now know a lot more about
> >> camel I think that this simple aproach will not really work. So this
> >> time I want to do this a little more structured. So I start with two
> >> simple goals:
> >>
> >> "The camel components should know as little as possible about camel
> >> core"
> >>
> >> "The classes needed to setup camel should be separate from the things
> >> needed at run time"
> >>
> >> So why should this be important? Currently components depend on
> >> camel-core as a whole and there are no further rules which classes the
> >> components should use and which classes should be private to core. Even
> >> classes from the impl package are needed. So this means that any
> >> refactoring we do in camel core could affect all components. As camel
> >> is growing steadily this can become quite problematic.
> >>
> >> So my idea would be to split camel-core into three parts:
> >>
> >> api, builder, impl
> >>
> >> These should be structured in a way that these big building blocks do
> >> not have cyclic dependencies. Any other cycles can be ignored in this
> >> step.
> >>
> >> As allowed depdencies I propose ( "->" means may use, depends on):
> >>
> >> * -> api
> >> end user config -> builder
> >> builder -> impl
> >>
> >> I think the first thing we should do is to discuss and reach a consensus
> >> about a basic architecure and rules like above. Then the next step is
> >> to assign each package of core to one of the basic parts. Then the next
> >> step is to resolve cycles between the parts.
> >>
> >> What do you think about these ideas?
> >>
> >> Thanks
> >>
> >> Christian
> >>
> >> Christian Schneider
> >> Informationsverarbeitung
> >> Business Solutions
> >> Handel und Dispatching
> >>
> >> Tel : +49-(0)721-63-15482
> >>
> >> EnBW Systeme Infrastruktur Support GmbH
> >> Sitz der Gesellschaft: Karlsruhe
> >> Handelsregister: Amtsgericht Mannheim - HRB 108550
> >> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
> >> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote:
> Hi
>
> I think the idea is really great, but I think the timing for this is
> *not* the right spot.
Why not?
>
> And by saying that I mean the goal of Camel 3.0 is to have a short
> development cycle (not like 2.0 which took a long time).
> And as a minimum (IMHO):
> - To upgrade to JDK 1.6+,
> - Spring 3.0+,
> - To optimize the router internally,
> - And to switch to slf4j logger (*)
> - Keeping backwards compatibility as much as possible with 2.x is paramount
Umm.. Everything listed there could go into a 2.6 release. I don't see any
reason for that to be what defines a 3.0 release.
If we are going to have a 3.0, lets get the work done that would need to be
done to provide a stable platform for the next year or so and provides the
API's and feature that are requried for the various new and exciting ideas
people are proposing.
Dan
> Switching to slf4j instead of commons logging, allows us to use the
> MDC logging feature.
> This allows us to push information to the logs such as message id,
> transaction id etc. which can more easily correlate logs, not only
> with Camel alone, but also with other projects such as ActiveMQ, SMX
> etc.
>
>
> On top of that we now have many 3rd party projects which integrate out
> of the box with Camel, so changing the package structure in camel-core
> will break their integration. Which means they may not take up the
> effort to support both Camel 2.x/3.x.
>
> However I do think we should take the effort and pick up the low
> hanging fruits. I am sure there could be a couple of tangles which can
> be identified and fixed in Camel 3.0, without breaking backwards
> compatibility.
>
> I think doing this is something for Camel 4 or 5 or 6 (or whatever
> future version it may be) when or if we change to use Scala and use
> some other framework as foundation. There are cool stuff being
> developed for ActiveMQ 6 which are potential as a backbone for route
> messages. And it has a much better threading model which Camel can
> benefit as well.
>
> Anyway practical works beats theory, so setting up a branch in the
> sandbox to do experiments is a great idea.
>
> But its very important that we keep backwards compatibility with Camel
> 3.0. There are so many people started using Camel 2.x now so we should
> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
> 2.x but now on JDK 1.6 and with X other internal upgrades.
>
> Okay my first cup of coffee is ready, so beware this mail was written
> before I got "my first fix".
>
> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> > I changed the thread name to [discuss].
> >
> > I like that idea and it's something we contemplated in the past. This
> > will bring back the idea of getting the dsl out of core as well.
> >
> > What I'd propose Christian is to add your proposal to the roadmap [1]. I
> > will do the same for the dsl idea. There at least 2 ideas for dsl's
> > built on top of the camel dsl (scheduling and debugging) that make me
> > even more interested in coming up with a better solution.
> >
> > Once we get some traction on the main refactoring ideas I'd suggest
> > starting one (or more) branches and start hacking, because there's not a
> > whole lot of time left if we want to meet our target.
> >
> > Cheers,
> > Hadrian
> >
> > [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
> >
> > On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
> >> Hi all,
> >>
> >> I will have some free time in december as I am changing my employer. So
> >> I am planning to work a little on some architectural improvements for
> >> camel 3.0.0. As these things are very critical to the stability of
> >> camel I would like to get feedback before I start any substantial work.
> >>
> >> As you surely know currently camel-core is quite tangled. So it is quite
> >> difficult where to start. Some time ago I proposed some improvements to
> >> simply reduce those dependency cycles. As I now know a lot more about
> >> camel I think that this simple aproach will not really work. So this
> >> time I want to do this a little more structured. So I start with two
> >> simple goals:
> >>
> >> "The camel components should know as little as possible about camel
> >> core"
> >>
> >> "The classes needed to setup camel should be separate from the things
> >> needed at run time"
> >>
> >> So why should this be important? Currently components depend on
> >> camel-core as a whole and there are no further rules which classes the
> >> components should use and which classes should be private to core. Even
> >> classes from the impl package are needed. So this means that any
> >> refactoring we do in camel core could affect all components. As camel
> >> is growing steadily this can become quite problematic.
> >>
> >> So my idea would be to split camel-core into three parts:
> >>
> >> api, builder, impl
> >>
> >> These should be structured in a way that these big building blocks do
> >> not have cyclic dependencies. Any other cycles can be ignored in this
> >> step.
> >>
> >> As allowed depdencies I propose ( "->" means may use, depends on):
> >>
> >> * -> api
> >> end user config -> builder
> >> builder -> impl
> >>
> >> I think the first thing we should do is to discuss and reach a consensus
> >> about a basic architecure and rules like above. Then the next step is
> >> to assign each package of core to one of the basic parts. Then the next
> >> step is to resolve cycles between the parts.
> >>
> >> What do you think about these ideas?
> >>
> >> Thanks
> >>
> >> Christian
> >>
> >> Christian Schneider
> >> Informationsverarbeitung
> >> Business Solutions
> >> Handel und Dispatching
> >>
> >> Tel : +49-(0)721-63-15482
> >>
> >> EnBW Systeme Infrastruktur Support GmbH
> >> Sitz der Gesellschaft: Karlsruhe
> >> Handelsregister: Amtsgericht Mannheim - HRB 108550
> >> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
> >> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Oct 19, 2010 at 6:44 AM, Johan Edstrom <se...@gmail.com> wrote:
> How do we help you?
>
About Camel 3.0?
Anyone who wants to contribute can of course help. We love
contributions at Apache.
And Johan just keep up a bit more and I am sure you got the attentions
of the PMCs to come onboard.
First I think we need Camel 2.5 to be shipped.
Then Hadrian can setup the 2.x branch and ensure trunk is ready for
Camel 3.0 development.
A rough plan for tasks to do could be something like this
- Then we can upgrade to JDK 1.6 and fix a few minor spots (eg
IOException now accepts nested exception, no need to use IOHelper)
- Removed @deprecated stuff from 2.x
- Upgrade to Spring 3.0
- Add SPEL (from Spring 3.0) as language to Camel
- There are potentially some code in the Camel spring namespace holder
which now may be obsolete by Spring 3 (check upon that)
- Upgrade to CXF 2.3 as people would like (eg it uses Jetty 7 and has
better continuations)
- Switch to use slf4j in camel-core, camel-spring and other important components
- And gradually switch to slf4j in the other camel components
- Use MDC in camel-core for enriching the logger with message id, tx
id (bread crumb, to trace message)
- Create camel-osgi-test for OSGi test kit
After all this work we can start looking into one of the tougher
pieces which is to optimize the internal router
- Reduce the need for copying the Exchange while routing
- Message facade with history and fix the useOriginalMessage
- Make the cross cutting concerns more dynamic (currently they are
statically woven into the route when the route is generated)
Instead it ought to be dynamic applied, so its much easier to
inject/remove interceptors, error handlers, and whatnot
And a ton of stuff which I may forgot.
And of course we will still continue doing the usual work of fixing
bugs, adding new components, improvements and what else the community
reports.
In terms of "package tangle" there could be some low hanging fruits.
There is a tool which can visualize the packages. Structure 101 which
is really good at this.
There are stuff which can be started already now, such as the
camel-osgi-test which ought to be able to backport to Camel 2.x as
well. We got some rough code in tests/camel-itest-osgi which "just"
needs to be polished and moved into a new component.
Okay getting ready for the 2nd cup now.
> On Oct 18, 2010, at 10:42 PM, Claus Ibsen wrote:
>
>> On Tue, Oct 19, 2010 at 6:40 AM, Johan Edstrom <se...@gmail.com> wrote:
>>> Since you did not get your Coffee :)
>>> Would you mind putting the hindrances up to the mere mortals?
>>>
>>
>> What do you mean?
>>
>>>
>>> On Oct 18, 2010, at 10:23 PM, Claus Ibsen wrote:
>>>
>>>> Hi
>>>>
>>>> I think the idea is really great, but I think the timing for this is
>>>> *not* the right spot.
>>>>
>>>> And by saying that I mean the goal of Camel 3.0 is to have a short
>>>> development cycle (not like 2.0 which took a long time).
>>>> And as a minimum (IMHO):
>>>> - To upgrade to JDK 1.6+,
>>>> - Spring 3.0+,
>>>> - To optimize the router internally,
>>>> - And to switch to slf4j logger (*)
>>>> - Keeping backwards compatibility as much as possible with 2.x is paramount
>>>>
>>>> Switching to slf4j instead of commons logging, allows us to use the
>>>> MDC logging feature.
>>>> This allows us to push information to the logs such as message id,
>>>> transaction id etc. which can more easily correlate logs, not only
>>>> with Camel alone, but also with other projects such as ActiveMQ, SMX
>>>> etc.
>>>>
>>>>
>>>> On top of that we now have many 3rd party projects which integrate out
>>>> of the box with Camel, so changing the package structure in camel-core
>>>> will break their integration. Which means they may not take up the
>>>> effort to support both Camel 2.x/3.x.
>>>>
>>>> However I do think we should take the effort and pick up the low
>>>> hanging fruits. I am sure there could be a couple of tangles which can
>>>> be identified and fixed in Camel 3.0, without breaking backwards
>>>> compatibility.
>>>>
>>>> I think doing this is something for Camel 4 or 5 or 6 (or whatever
>>>> future version it may be) when or if we change to use Scala and use
>>>> some other framework as foundation. There are cool stuff being
>>>> developed for ActiveMQ 6 which are potential as a backbone for route
>>>> messages. And it has a much better threading model which Camel can
>>>> benefit as well.
>>>>
>>>> Anyway practical works beats theory, so setting up a branch in the
>>>> sandbox to do experiments is a great idea.
>>>>
>>>> But its very important that we keep backwards compatibility with Camel
>>>> 3.0. There are so many people started using Camel 2.x now so we should
>>>> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
>>>> 2.x but now on JDK 1.6 and with X other internal upgrades.
>>>>
>>>> Okay my first cup of coffee is ready, so beware this mail was written
>>>> before I got "my first fix".
>>>>
>>>>
>>>>
>>>> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>>>> I changed the thread name to [discuss].
>>>>>
>>>>> I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
>>>>>
>>>>> What I'd propose Christian is to add your proposal to the roadmap [1]. I will do the same for the dsl idea. There at least 2 ideas for dsl's built on top of the camel dsl (scheduling and debugging) that make me even more interested in coming up with a better solution.
>>>>>
>>>>> Once we get some traction on the main refactoring ideas I'd suggest starting one (or more) branches and start hacking, because there's not a whole lot of time left if we want to meet our target.
>>>>>
>>>>> Cheers,
>>>>> Hadrian
>>>>>
>>>>> [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>>>>>
>>>>>
>>>>>
>>>>> On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I will have some free time in december as I am changing my employer. So I am planning to work a little on some architectural improvements for camel 3.0.0. As these things are very critical to the stability of camel I would like to get feedback before I start any substantial work.
>>>>>>
>>>>>> As you surely know currently camel-core is quite tangled. So it is quite difficult where to start. Some time ago I proposed some improvements to simply reduce those dependency cycles. As I now know a lot more about camel I think that this simple aproach will not really work. So this time I want to do this a little more structured. So I start with two simple goals:
>>>>>>
>>>>>> "The camel components should know as little as possible about camel core"
>>>>>>
>>>>>> "The classes needed to setup camel should be separate from the things needed at run time"
>>>>>>
>>>>>> So why should this be important? Currently components depend on camel-core as a whole and there are no further rules which classes the components should use and which classes should be private to core. Even classes from the impl package are needed. So this means that any refactoring we do in camel core could affect all components. As camel is growing steadily this can become quite problematic.
>>>>>>
>>>>>> So my idea would be to split camel-core into three parts:
>>>>>>
>>>>>> api, builder, impl
>>>>>>
>>>>>> These should be structured in a way that these big building blocks do not have cyclic dependencies. Any other cycles can be ignored in this step.
>>>>>>
>>>>>> As allowed depdencies I propose ( "->" means may use, depends on):
>>>>>>
>>>>>> * -> api
>>>>>> end user config -> builder
>>>>>> builder -> impl
>>>>>>
>>>>>> I think the first thing we should do is to discuss and reach a consensus about a basic architecure and rules like above. Then the next step is to assign each package of core to one of the basic parts. Then the next step is to resolve cycles between the parts.
>>>>>>
>>>>>> What do you think about these ideas?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> Christian Schneider
>>>>>> Informationsverarbeitung
>>>>>> Business Solutions
>>>>>> Handel und Dispatching
>>>>>>
>>>>>> Tel : +49-(0)721-63-15482
>>>>>>
>>>>>> EnBW Systeme Infrastruktur Support GmbH
>>>>>> Sitz der Gesellschaft: Karlsruhe
>>>>>> Handelsregister: Amtsgericht Mannheim - HRB 108550
>>>>>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>>>>>> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> Apache Camel Committer
>>>>
>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>> Open Source Integration: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Twitter: http://twitter.com/davsclaus
>>>
>>> Johan Edstrom
>>>
>>> joed@opennms.org
>>>
>>> They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety.
>>>
>>> Benjamin Franklin, Historical Review of Pennsylvania, 1759
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>
> Johan Edstrom
>
> joed@opennms.org
>
> They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety.
>
> Benjamin Franklin, Historical Review of Pennsylvania, 1759
>
>
>
>
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Johan Edstrom <se...@gmail.com>.
How do we help you?
On Oct 18, 2010, at 10:42 PM, Claus Ibsen wrote:
> On Tue, Oct 19, 2010 at 6:40 AM, Johan Edstrom <se...@gmail.com> wrote:
>> Since you did not get your Coffee :)
>> Would you mind putting the hindrances up to the mere mortals?
>>
>
> What do you mean?
>
>>
>> On Oct 18, 2010, at 10:23 PM, Claus Ibsen wrote:
>>
>>> Hi
>>>
>>> I think the idea is really great, but I think the timing for this is
>>> *not* the right spot.
>>>
>>> And by saying that I mean the goal of Camel 3.0 is to have a short
>>> development cycle (not like 2.0 which took a long time).
>>> And as a minimum (IMHO):
>>> - To upgrade to JDK 1.6+,
>>> - Spring 3.0+,
>>> - To optimize the router internally,
>>> - And to switch to slf4j logger (*)
>>> - Keeping backwards compatibility as much as possible with 2.x is paramount
>>>
>>> Switching to slf4j instead of commons logging, allows us to use the
>>> MDC logging feature.
>>> This allows us to push information to the logs such as message id,
>>> transaction id etc. which can more easily correlate logs, not only
>>> with Camel alone, but also with other projects such as ActiveMQ, SMX
>>> etc.
>>>
>>>
>>> On top of that we now have many 3rd party projects which integrate out
>>> of the box with Camel, so changing the package structure in camel-core
>>> will break their integration. Which means they may not take up the
>>> effort to support both Camel 2.x/3.x.
>>>
>>> However I do think we should take the effort and pick up the low
>>> hanging fruits. I am sure there could be a couple of tangles which can
>>> be identified and fixed in Camel 3.0, without breaking backwards
>>> compatibility.
>>>
>>> I think doing this is something for Camel 4 or 5 or 6 (or whatever
>>> future version it may be) when or if we change to use Scala and use
>>> some other framework as foundation. There are cool stuff being
>>> developed for ActiveMQ 6 which are potential as a backbone for route
>>> messages. And it has a much better threading model which Camel can
>>> benefit as well.
>>>
>>> Anyway practical works beats theory, so setting up a branch in the
>>> sandbox to do experiments is a great idea.
>>>
>>> But its very important that we keep backwards compatibility with Camel
>>> 3.0. There are so many people started using Camel 2.x now so we should
>>> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
>>> 2.x but now on JDK 1.6 and with X other internal upgrades.
>>>
>>> Okay my first cup of coffee is ready, so beware this mail was written
>>> before I got "my first fix".
>>>
>>>
>>>
>>> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>>> I changed the thread name to [discuss].
>>>>
>>>> I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
>>>>
>>>> What I'd propose Christian is to add your proposal to the roadmap [1]. I will do the same for the dsl idea. There at least 2 ideas for dsl's built on top of the camel dsl (scheduling and debugging) that make me even more interested in coming up with a better solution.
>>>>
>>>> Once we get some traction on the main refactoring ideas I'd suggest starting one (or more) branches and start hacking, because there's not a whole lot of time left if we want to meet our target.
>>>>
>>>> Cheers,
>>>> Hadrian
>>>>
>>>> [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>>>>
>>>>
>>>>
>>>> On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I will have some free time in december as I am changing my employer. So I am planning to work a little on some architectural improvements for camel 3.0.0. As these things are very critical to the stability of camel I would like to get feedback before I start any substantial work.
>>>>>
>>>>> As you surely know currently camel-core is quite tangled. So it is quite difficult where to start. Some time ago I proposed some improvements to simply reduce those dependency cycles. As I now know a lot more about camel I think that this simple aproach will not really work. So this time I want to do this a little more structured. So I start with two simple goals:
>>>>>
>>>>> "The camel components should know as little as possible about camel core"
>>>>>
>>>>> "The classes needed to setup camel should be separate from the things needed at run time"
>>>>>
>>>>> So why should this be important? Currently components depend on camel-core as a whole and there are no further rules which classes the components should use and which classes should be private to core. Even classes from the impl package are needed. So this means that any refactoring we do in camel core could affect all components. As camel is growing steadily this can become quite problematic.
>>>>>
>>>>> So my idea would be to split camel-core into three parts:
>>>>>
>>>>> api, builder, impl
>>>>>
>>>>> These should be structured in a way that these big building blocks do not have cyclic dependencies. Any other cycles can be ignored in this step.
>>>>>
>>>>> As allowed depdencies I propose ( "->" means may use, depends on):
>>>>>
>>>>> * -> api
>>>>> end user config -> builder
>>>>> builder -> impl
>>>>>
>>>>> I think the first thing we should do is to discuss and reach a consensus about a basic architecure and rules like above. Then the next step is to assign each package of core to one of the basic parts. Then the next step is to resolve cycles between the parts.
>>>>>
>>>>> What do you think about these ideas?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Christian
>>>>>
>>>>> Christian Schneider
>>>>> Informationsverarbeitung
>>>>> Business Solutions
>>>>> Handel und Dispatching
>>>>>
>>>>> Tel : +49-(0)721-63-15482
>>>>>
>>>>> EnBW Systeme Infrastruktur Support GmbH
>>>>> Sitz der Gesellschaft: Karlsruhe
>>>>> Handelsregister: Amtsgericht Mannheim - HRB 108550
>>>>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>>>>> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>
>> Johan Edstrom
>>
>> joed@opennms.org
>>
>> They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety.
>>
>> Benjamin Franklin, Historical Review of Pennsylvania, 1759
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
Johan Edstrom
joed@opennms.org
They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety.
Benjamin Franklin, Historical Review of Pennsylvania, 1759
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Oct 19, 2010 at 6:40 AM, Johan Edstrom <se...@gmail.com> wrote:
> Since you did not get your Coffee :)
> Would you mind putting the hindrances up to the mere mortals?
>
What do you mean?
>
> On Oct 18, 2010, at 10:23 PM, Claus Ibsen wrote:
>
>> Hi
>>
>> I think the idea is really great, but I think the timing for this is
>> *not* the right spot.
>>
>> And by saying that I mean the goal of Camel 3.0 is to have a short
>> development cycle (not like 2.0 which took a long time).
>> And as a minimum (IMHO):
>> - To upgrade to JDK 1.6+,
>> - Spring 3.0+,
>> - To optimize the router internally,
>> - And to switch to slf4j logger (*)
>> - Keeping backwards compatibility as much as possible with 2.x is paramount
>>
>> Switching to slf4j instead of commons logging, allows us to use the
>> MDC logging feature.
>> This allows us to push information to the logs such as message id,
>> transaction id etc. which can more easily correlate logs, not only
>> with Camel alone, but also with other projects such as ActiveMQ, SMX
>> etc.
>>
>>
>> On top of that we now have many 3rd party projects which integrate out
>> of the box with Camel, so changing the package structure in camel-core
>> will break their integration. Which means they may not take up the
>> effort to support both Camel 2.x/3.x.
>>
>> However I do think we should take the effort and pick up the low
>> hanging fruits. I am sure there could be a couple of tangles which can
>> be identified and fixed in Camel 3.0, without breaking backwards
>> compatibility.
>>
>> I think doing this is something for Camel 4 or 5 or 6 (or whatever
>> future version it may be) when or if we change to use Scala and use
>> some other framework as foundation. There are cool stuff being
>> developed for ActiveMQ 6 which are potential as a backbone for route
>> messages. And it has a much better threading model which Camel can
>> benefit as well.
>>
>> Anyway practical works beats theory, so setting up a branch in the
>> sandbox to do experiments is a great idea.
>>
>> But its very important that we keep backwards compatibility with Camel
>> 3.0. There are so many people started using Camel 2.x now so we should
>> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
>> 2.x but now on JDK 1.6 and with X other internal upgrades.
>>
>> Okay my first cup of coffee is ready, so beware this mail was written
>> before I got "my first fix".
>>
>>
>>
>> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>> I changed the thread name to [discuss].
>>>
>>> I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
>>>
>>> What I'd propose Christian is to add your proposal to the roadmap [1]. I will do the same for the dsl idea. There at least 2 ideas for dsl's built on top of the camel dsl (scheduling and debugging) that make me even more interested in coming up with a better solution.
>>>
>>> Once we get some traction on the main refactoring ideas I'd suggest starting one (or more) branches and start hacking, because there's not a whole lot of time left if we want to meet our target.
>>>
>>> Cheers,
>>> Hadrian
>>>
>>> [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>>>
>>>
>>>
>>> On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>>>
>>>> Hi all,
>>>>
>>>> I will have some free time in december as I am changing my employer. So I am planning to work a little on some architectural improvements for camel 3.0.0. As these things are very critical to the stability of camel I would like to get feedback before I start any substantial work.
>>>>
>>>> As you surely know currently camel-core is quite tangled. So it is quite difficult where to start. Some time ago I proposed some improvements to simply reduce those dependency cycles. As I now know a lot more about camel I think that this simple aproach will not really work. So this time I want to do this a little more structured. So I start with two simple goals:
>>>>
>>>> "The camel components should know as little as possible about camel core"
>>>>
>>>> "The classes needed to setup camel should be separate from the things needed at run time"
>>>>
>>>> So why should this be important? Currently components depend on camel-core as a whole and there are no further rules which classes the components should use and which classes should be private to core. Even classes from the impl package are needed. So this means that any refactoring we do in camel core could affect all components. As camel is growing steadily this can become quite problematic.
>>>>
>>>> So my idea would be to split camel-core into three parts:
>>>>
>>>> api, builder, impl
>>>>
>>>> These should be structured in a way that these big building blocks do not have cyclic dependencies. Any other cycles can be ignored in this step.
>>>>
>>>> As allowed depdencies I propose ( "->" means may use, depends on):
>>>>
>>>> * -> api
>>>> end user config -> builder
>>>> builder -> impl
>>>>
>>>> I think the first thing we should do is to discuss and reach a consensus about a basic architecure and rules like above. Then the next step is to assign each package of core to one of the basic parts. Then the next step is to resolve cycles between the parts.
>>>>
>>>> What do you think about these ideas?
>>>>
>>>> Thanks
>>>>
>>>> Christian
>>>>
>>>> Christian Schneider
>>>> Informationsverarbeitung
>>>> Business Solutions
>>>> Handel und Dispatching
>>>>
>>>> Tel : +49-(0)721-63-15482
>>>>
>>>> EnBW Systeme Infrastruktur Support GmbH
>>>> Sitz der Gesellschaft: Karlsruhe
>>>> Handelsregister: Amtsgericht Mannheim - HRB 108550
>>>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>>>> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>
> Johan Edstrom
>
> joed@opennms.org
>
> They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety.
>
> Benjamin Franklin, Historical Review of Pennsylvania, 1759
>
>
>
>
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Johan Edstrom <se...@gmail.com>.
Since you did not get your Coffee :)
Would you mind putting the hindrances up to the mere mortals?
On Oct 18, 2010, at 10:23 PM, Claus Ibsen wrote:
> Hi
>
> I think the idea is really great, but I think the timing for this is
> *not* the right spot.
>
> And by saying that I mean the goal of Camel 3.0 is to have a short
> development cycle (not like 2.0 which took a long time).
> And as a minimum (IMHO):
> - To upgrade to JDK 1.6+,
> - Spring 3.0+,
> - To optimize the router internally,
> - And to switch to slf4j logger (*)
> - Keeping backwards compatibility as much as possible with 2.x is paramount
>
> Switching to slf4j instead of commons logging, allows us to use the
> MDC logging feature.
> This allows us to push information to the logs such as message id,
> transaction id etc. which can more easily correlate logs, not only
> with Camel alone, but also with other projects such as ActiveMQ, SMX
> etc.
>
>
> On top of that we now have many 3rd party projects which integrate out
> of the box with Camel, so changing the package structure in camel-core
> will break their integration. Which means they may not take up the
> effort to support both Camel 2.x/3.x.
>
> However I do think we should take the effort and pick up the low
> hanging fruits. I am sure there could be a couple of tangles which can
> be identified and fixed in Camel 3.0, without breaking backwards
> compatibility.
>
> I think doing this is something for Camel 4 or 5 or 6 (or whatever
> future version it may be) when or if we change to use Scala and use
> some other framework as foundation. There are cool stuff being
> developed for ActiveMQ 6 which are potential as a backbone for route
> messages. And it has a much better threading model which Camel can
> benefit as well.
>
> Anyway practical works beats theory, so setting up a branch in the
> sandbox to do experiments is a great idea.
>
> But its very important that we keep backwards compatibility with Camel
> 3.0. There are so many people started using Camel 2.x now so we should
> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
> 2.x but now on JDK 1.6 and with X other internal upgrades.
>
> Okay my first cup of coffee is ready, so beware this mail was written
> before I got "my first fix".
>
>
>
> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> I changed the thread name to [discuss].
>>
>> I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
>>
>> What I'd propose Christian is to add your proposal to the roadmap [1]. I will do the same for the dsl idea. There at least 2 ideas for dsl's built on top of the camel dsl (scheduling and debugging) that make me even more interested in coming up with a better solution.
>>
>> Once we get some traction on the main refactoring ideas I'd suggest starting one (or more) branches and start hacking, because there's not a whole lot of time left if we want to meet our target.
>>
>> Cheers,
>> Hadrian
>>
>> [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>>
>>
>>
>> On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>>
>>> Hi all,
>>>
>>> I will have some free time in december as I am changing my employer. So I am planning to work a little on some architectural improvements for camel 3.0.0. As these things are very critical to the stability of camel I would like to get feedback before I start any substantial work.
>>>
>>> As you surely know currently camel-core is quite tangled. So it is quite difficult where to start. Some time ago I proposed some improvements to simply reduce those dependency cycles. As I now know a lot more about camel I think that this simple aproach will not really work. So this time I want to do this a little more structured. So I start with two simple goals:
>>>
>>> "The camel components should know as little as possible about camel core"
>>>
>>> "The classes needed to setup camel should be separate from the things needed at run time"
>>>
>>> So why should this be important? Currently components depend on camel-core as a whole and there are no further rules which classes the components should use and which classes should be private to core. Even classes from the impl package are needed. So this means that any refactoring we do in camel core could affect all components. As camel is growing steadily this can become quite problematic.
>>>
>>> So my idea would be to split camel-core into three parts:
>>>
>>> api, builder, impl
>>>
>>> These should be structured in a way that these big building blocks do not have cyclic dependencies. Any other cycles can be ignored in this step.
>>>
>>> As allowed depdencies I propose ( "->" means may use, depends on):
>>>
>>> * -> api
>>> end user config -> builder
>>> builder -> impl
>>>
>>> I think the first thing we should do is to discuss and reach a consensus about a basic architecure and rules like above. Then the next step is to assign each package of core to one of the basic parts. Then the next step is to resolve cycles between the parts.
>>>
>>> What do you think about these ideas?
>>>
>>> Thanks
>>>
>>> Christian
>>>
>>> Christian Schneider
>>> Informationsverarbeitung
>>> Business Solutions
>>> Handel und Dispatching
>>>
>>> Tel : +49-(0)721-63-15482
>>>
>>> EnBW Systeme Infrastruktur Support GmbH
>>> Sitz der Gesellschaft: Karlsruhe
>>> Handelsregister: Amtsgericht Mannheim - HRB 108550
>>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>>> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
Johan Edstrom
joed@opennms.org
They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety.
Benjamin Franklin, Historical Review of Pennsylvania, 1759
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I think the idea is really great, but I think the timing for this is
*not* the right spot.
And by saying that I mean the goal of Camel 3.0 is to have a short
development cycle (not like 2.0 which took a long time).
And as a minimum (IMHO):
- To upgrade to JDK 1.6+,
- Spring 3.0+,
- To optimize the router internally,
- And to switch to slf4j logger (*)
- Keeping backwards compatibility as much as possible with 2.x is paramount
Switching to slf4j instead of commons logging, allows us to use the
MDC logging feature.
This allows us to push information to the logs such as message id,
transaction id etc. which can more easily correlate logs, not only
with Camel alone, but also with other projects such as ActiveMQ, SMX
etc.
On top of that we now have many 3rd party projects which integrate out
of the box with Camel, so changing the package structure in camel-core
will break their integration. Which means they may not take up the
effort to support both Camel 2.x/3.x.
However I do think we should take the effort and pick up the low
hanging fruits. I am sure there could be a couple of tangles which can
be identified and fixed in Camel 3.0, without breaking backwards
compatibility.
I think doing this is something for Camel 4 or 5 or 6 (or whatever
future version it may be) when or if we change to use Scala and use
some other framework as foundation. There are cool stuff being
developed for ActiveMQ 6 which are potential as a backbone for route
messages. And it has a much better threading model which Camel can
benefit as well.
Anyway practical works beats theory, so setting up a branch in the
sandbox to do experiments is a great idea.
But its very important that we keep backwards compatibility with Camel
3.0. There are so many people started using Camel 2.x now so we should
keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
2.x but now on JDK 1.6 and with X other internal upgrades.
Okay my first cup of coffee is ready, so beware this mail was written
before I got "my first fix".
On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> I changed the thread name to [discuss].
>
> I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
>
> What I'd propose Christian is to add your proposal to the roadmap [1]. I will do the same for the dsl idea. There at least 2 ideas for dsl's built on top of the camel dsl (scheduling and debugging) that make me even more interested in coming up with a better solution.
>
> Once we get some traction on the main refactoring ideas I'd suggest starting one (or more) branches and start hacking, because there's not a whole lot of time left if we want to meet our target.
>
> Cheers,
> Hadrian
>
> [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>
>
>
> On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote:
>
>> Hi all,
>>
>> I will have some free time in december as I am changing my employer. So I am planning to work a little on some architectural improvements for camel 3.0.0. As these things are very critical to the stability of camel I would like to get feedback before I start any substantial work.
>>
>> As you surely know currently camel-core is quite tangled. So it is quite difficult where to start. Some time ago I proposed some improvements to simply reduce those dependency cycles. As I now know a lot more about camel I think that this simple aproach will not really work. So this time I want to do this a little more structured. So I start with two simple goals:
>>
>> "The camel components should know as little as possible about camel core"
>>
>> "The classes needed to setup camel should be separate from the things needed at run time"
>>
>> So why should this be important? Currently components depend on camel-core as a whole and there are no further rules which classes the components should use and which classes should be private to core. Even classes from the impl package are needed. So this means that any refactoring we do in camel core could affect all components. As camel is growing steadily this can become quite problematic.
>>
>> So my idea would be to split camel-core into three parts:
>>
>> api, builder, impl
>>
>> These should be structured in a way that these big building blocks do not have cyclic dependencies. Any other cycles can be ignored in this step.
>>
>> As allowed depdencies I propose ( "->" means may use, depends on):
>>
>> * -> api
>> end user config -> builder
>> builder -> impl
>>
>> I think the first thing we should do is to discuss and reach a consensus about a basic architecure and rules like above. Then the next step is to assign each package of core to one of the basic parts. Then the next step is to resolve cycles between the parts.
>>
>> What do you think about these ideas?
>>
>> Thanks
>>
>> Christian
>>
>> Christian Schneider
>> Informationsverarbeitung
>> Business Solutions
>> Handel und Dispatching
>>
>> Tel : +49-(0)721-63-15482
>>
>> EnBW Systeme Infrastruktur Support GmbH
>> Sitz der Gesellschaft: Karlsruhe
>> Handelsregister: Amtsgericht Mannheim - HRB 108550
>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>>
>>
>>
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by James Strachan <ja...@gmail.com>.
On 19 October 2010 14:51, Hadrian Zbarcea <hz...@gmail.com> wrote:
> The benefit if allowing developers to have their dsl that extends the camel dsl. I get asked this question now and then (last time yesterday).
> The only way to do it now is to have a separate dsl on top of the camel dsl.
Huh? Anyone can define any DSL in any class anywhere and use as much
or as little of the Camel DSL as they like. Thats not an argument for
separating the Camel DSL from the JAXB model.
> And the dsl is not that unified and you know it.
Moving it away from the JAXB model will help unify the DSL how exactly?
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by Hadrian Zbarcea <hz...@gmail.com>.
The benefit if allowing developers to have their dsl that extends the camel dsl. I get asked this question now and then (last time yesterday).
The only way to do it now is to have a separate dsl on top of the camel dsl. And the dsl is not that unified and you know it.
Hadrian
On Oct 19, 2010, at 8:34 AM, James Strachan wrote:
> On 18 October 2010 18:28, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> I changed the thread name to [discuss].
>>
>> I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
>
> What benefits does that have BTW? IMHO more dependencies for no actual
> gain has negative value.
>
> FWIW early camel had Java DSL separate from the JAXB model and it was
> a maintenance nightmare which is why we unified it into the same
> model.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
Re: [DISCUSS] Some thoughts about the architecture of camel
Posted by James Strachan <ja...@gmail.com>.
On 18 October 2010 18:28, Hadrian Zbarcea <hz...@gmail.com> wrote:
> I changed the thread name to [discuss].
>
> I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
What benefits does that have BTW? IMHO more dependencies for no actual
gain has negative value.
FWIW early camel had Java DSL separate from the JAXB model and it was
a maintenance nightmare which is why we unified it into the same
model.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/