You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Schneider Christian <Ch...@enbw.com> on 2010/10/18 11:43:27 UTC
Some thoughts about the architecture of camel
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 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/
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
[DISCUSS] Some thoughts about the architecture of camel
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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: Some thoughts about the architecture of camel
Posted by Willem Jiang <wi...@gmail.com>.
On 10/19/10 11:36 PM, Hadrian Zbarcea wrote:
> Comments inline.
>
> Hadrian
>
> On Oct 19, 2010, at 10:19 AM, Claus Ibsen wrote:
>
>> On Tue, Oct 19, 2010 at 3:55 PM, Hadrian Zbarcea<hz...@gmail.com> wrote:
>>> I think we should take this as a separate discussion. The partial results from the recent survey (which I hope you did fill in)
>>> show that not many still use java5. Given the problems it causes for the release, I see it as a very good idea to move to jdk6 in camel 2.6. You can still use 2.5 for many months to come, until you decide to upgrade to jdk6, for once, and then we can also have 2.5.x maintenance releases (more rare I hope) for those still interested in using jdk5.
>>>
>>
>> Sorry but I think this message will really confuse end users and even our self.
>>
>> Having Camel 2.x = JDK 1.5 / Spring 2.5 / ( and Spring 3.0 support
>> from Camel 2.3/4 onwards). Hey even Spring 2.0 is still support I
>> think.
> Why do you equate Camel 2.x with jdk 1.5 and spring 2.5? As you know camel-web, which we distribute, *only* works with jdk 1.6.
> We also use junit 3.8.2 and 4.8.1 and various versions of a bunch of dependent jars, that get upgraded from a camel release to another.
> Granted the jdk version is very important, but we made the decision of only supporting jdk 1.6 (for a subset of the components at least) when we added the jersey dependency.
>
Just like the Spring 3 supports JDK5, but the Spring 2.x also has some
modules that can only run with JDK5. It make sense to announce Camel 3.x
only supports JDK6, and it could be easy for us to clean up the backward
compatible codes (to support Spring 2.x, JDK 5) in Camel 3.
>
>> Now that gets messy if Camel 2.6 is suddenly something else.
> What are you talking about. What else?
>
>> Also in the light how we have always done releases at Apache. One
>> major after the other. 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6 and so forth.
>> We started maintenance mode of Camel 1.x in the 1.6 line (albeit Camel
>> 1.6.1 should really have been Camel 1.7 since there so many changes in
>> it.).
> Point being?
We are talking about breaking the backward compatible of the most
popular third part libs, and it's a major release thing.
>
>> It will in fact start to confuse / scare people if Camel 2.5 is
>> already in the "maintenance mode" and the next expected release would
>> be Camel 2.5.1.
> I promise to withdraw my proposal (which is not formal yet, but I intend to make it a formal proposal once the survey results are out)
> to only support jdk 1.6 from camel 2.6 onwards if I hear *one* developer (seriously) saying that he'd be scared if:
> * camel 2.6 and onwards on the 2.x line will only support jdk 1.6
> * camel 2.5.x will continue to be maintained and supported on jdk 1.5
> My thoughts are based on the intermediate results of the survey and the cost to support jdk 1.5
>
>
>>> I think better is to have a discussion and make a decision regarding jdk5 support after the survey results are final.
> There, I am repeating myself.
I have strong feeling that most user are still using JDK 1.5, but it
don't mean we can't upgrade to JDK 1.6. We can keep providing some
candies in Camel 3.x for user to use :)
>
>
>>>
>>> Cheers,
>>> Hadrian
>>>
>>>
>>>
>>> On Oct 19, 2010, at 9:31 AM, Richard Kettelerij wrote:
>>>
>>>> Concerning the 2.0 vs. 3.0 debate. I agree with James and Claus that it
>>>> would be better to change the major version when you require Spring 3.0 and
>>>> Java 6.
>>>>
>>>> To illustrate, I'm still stuck at Java 5 (we'll probably move to Java 6 in
>>>> 2011 Q1), so upgrading to Camel 3.0 isn't possible. Nevertheless when Camel
>>>> 3.0 is in development I would still love to see blocking issues being fixed
>>>> on the 2.x branch. Changing the major version makes this possible (like you
>>>> guys did with the 1.x branch).
>>>>
>>>> On Tue, Oct 19, 2010 at 2:59 PM, Schneider Christian<
>>>> Christian.Schneider@enbw.com> wrote:
>>>>
>>>>> Hi James,
>>>>>
>>>>> it is not absolutely necessary to split the jar into three jars. More
>>>>> important is to have rules that say that a component developer should only
>>>>> depdend on the API part and to check that the internal dependencies do not
>>>>> have cycles between the three logical modules. The only disadvantage of not
>>>>> breaking up camel core into three modules is that maven will not help you in
>>>>> avoiding cycles which would be the case with separate modules. As the rules
>>>>> can be checked with tools like structure 101 this is not too bad though.
>>>>>
>>>>> I don´t think the cyclic depdencies are only a "metric". They are a real
>>>>> problem when the code grows as you can not understand or change anything
>>>>> isolated. To have three clearly defined parts in camel core that should not
>>>>> have cycles between them is quite reasonable imho.
>>>>>
>>>>> Especially I think the builders should be separated as they are not needed
>>>>> at runtime. The builder pattern creates many cycles and it confuses people
>>>>> who try to understand the runtime behaviour. Of course I do not speak
>>>>> against builders and the dsl. They are extremely convenient and clear to use
>>>>> for end users and make a good part of the appeal of camel.
>>>>>
>>>>> So to sum it up I think breaking up camel-core logically is very important.
>>>>> At the same time I understand that ease of use is a value that is probably
>>>>> as important as a clear architecture. The good thing is that I am quite sure
>>>>> that we can achieve both.
>>>>>
>>>>> 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: James Strachan [mailto:james.strachan@gmail.com]
>>>>> Gesendet: Dienstag, 19. Oktober 2010 14:31
>>>>> An: dev@camel.apache.org
>>>>> Betreff: Re: Some thoughts about the architecture of camel
>>>>>
>>>>>
>>>>>>
>>>>>> So my idea would be to split camel-core into three parts:
>>>>>>
>>>>>> api, builder, impl
>>>>>
>>>>> What benefits do you see for end users and component developers having
>>>>> to depend on at least 3 jars rather than one?
>>>>>
>>>>> One of the reasons I like camel-core as it is; its nice and simple and
>>>>> just works. You can build& run routes with some simple components
>>>>> using the single camel-core jar. (Just add camel-test to do testing).
>>>>>
>>>>> Sure there's some cyclic package dependencies. Given the large number
>>>>> of use cases in Camel (route design, testing, JAXB model, Java DSL and
>>>>> base set of components) its kinda hard to totally avoid those while
>>>>> having convention over configuration, decent defaults etc.
>>>>>
>>>>> I value ease of use for end users& component developers and backwards
>>>>> compatibility over cyclic dependency metrics any day :)
>>>>>
>>>>> --
>>>>> James
>>>>> -------
>>>>> http://macstrac.blogspot.com/
>>>>>
>>>>> Open Source Integration
>>>>> http://fusesource.com/
>>>>>
>>>
>>>
>>
>>
>>
>> --
>> 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
>
>
--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang
Re: Some thoughts about the architecture of camel
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Hadrian,
+1
for project integrating Camel (such as ServiceMix), it will be more
flexible in that way.
Regards
JB
On 10/19/2010 06:03 PM, Hadrian Zbarcea wrote:
> Here's another thought.
>
> We will continue to support 2.x for at least another year. Would it be less confusing if we released 2.6 in Dec, and 2.6.x in 2011 (when needed) on jdk 1.5 and the other 2.7 and up releases on jdk 1.6 only? Give people enough heads up to get used to the idea?
>
> How does that sound?
>
> Hadrian
>
>
>>> It will in fact start to confuse / scare people if Camel 2.5 is
>>> already in the "maintenance mode" and the next expected release would
>>> be Camel 2.5.1.
>> I promise to withdraw my proposal (which is not formal yet, but I intend to make it a formal proposal once the survey results are out)
>> to only support jdk 1.6 from camel 2.6 onwards if I hear *one* developer (seriously) saying that he'd be scared if:
>> * camel 2.6 and onwards on the 2.x line will only support jdk 1.6
>> * camel 2.5.x will continue to be maintained and supported on jdk 1.5
>> My thoughts are based on the intermediate results of the survey and the cost to support jdk 1.5
>
>
>
Re: Some thoughts about the architecture of camel
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Here's another thought.
We will continue to support 2.x for at least another year. Would it be less confusing if we released 2.6 in Dec, and 2.6.x in 2011 (when needed) on jdk 1.5 and the other 2.7 and up releases on jdk 1.6 only? Give people enough heads up to get used to the idea?
How does that sound?
Hadrian
>> It will in fact start to confuse / scare people if Camel 2.5 is
>> already in the "maintenance mode" and the next expected release would
>> be Camel 2.5.1.
> I promise to withdraw my proposal (which is not formal yet, but I intend to make it a formal proposal once the survey results are out)
> to only support jdk 1.6 from camel 2.6 onwards if I hear *one* developer (seriously) saying that he'd be scared if:
> * camel 2.6 and onwards on the 2.x line will only support jdk 1.6
> * camel 2.5.x will continue to be maintained and supported on jdk 1.5
> My thoughts are based on the intermediate results of the survey and the cost to support jdk 1.5
Re: Some thoughts about the architecture of camel
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Comments inline.
Hadrian
On Oct 19, 2010, at 10:19 AM, Claus Ibsen wrote:
> On Tue, Oct 19, 2010 at 3:55 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> I think we should take this as a separate discussion. The partial results from the recent survey (which I hope you did fill in)
>> show that not many still use java5. Given the problems it causes for the release, I see it as a very good idea to move to jdk6 in camel 2.6. You can still use 2.5 for many months to come, until you decide to upgrade to jdk6, for once, and then we can also have 2.5.x maintenance releases (more rare I hope) for those still interested in using jdk5.
>>
>
> Sorry but I think this message will really confuse end users and even our self.
>
> Having Camel 2.x = JDK 1.5 / Spring 2.5 / ( and Spring 3.0 support
> from Camel 2.3/4 onwards). Hey even Spring 2.0 is still support I
> think.
Why do you equate Camel 2.x with jdk 1.5 and spring 2.5? As you know camel-web, which we distribute, *only* works with jdk 1.6.
We also use junit 3.8.2 and 4.8.1 and various versions of a bunch of dependent jars, that get upgraded from a camel release to another.
Granted the jdk version is very important, but we made the decision of only supporting jdk 1.6 (for a subset of the components at least) when we added the jersey dependency.
> Now that gets messy if Camel 2.6 is suddenly something else.
What are you talking about. What else?
> Also in the light how we have always done releases at Apache. One
> major after the other. 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6 and so forth.
> We started maintenance mode of Camel 1.x in the 1.6 line (albeit Camel
> 1.6.1 should really have been Camel 1.7 since there so many changes in
> it.).
Point being?
> It will in fact start to confuse / scare people if Camel 2.5 is
> already in the "maintenance mode" and the next expected release would
> be Camel 2.5.1.
I promise to withdraw my proposal (which is not formal yet, but I intend to make it a formal proposal once the survey results are out)
to only support jdk 1.6 from camel 2.6 onwards if I hear *one* developer (seriously) saying that he'd be scared if:
* camel 2.6 and onwards on the 2.x line will only support jdk 1.6
* camel 2.5.x will continue to be maintained and supported on jdk 1.5
My thoughts are based on the intermediate results of the survey and the cost to support jdk 1.5
>> I think better is to have a discussion and make a decision regarding jdk5 support after the survey results are final.
There, I am repeating myself.
>>
>> Cheers,
>> Hadrian
>>
>>
>>
>> On Oct 19, 2010, at 9:31 AM, Richard Kettelerij wrote:
>>
>>> Concerning the 2.0 vs. 3.0 debate. I agree with James and Claus that it
>>> would be better to change the major version when you require Spring 3.0 and
>>> Java 6.
>>>
>>> To illustrate, I'm still stuck at Java 5 (we'll probably move to Java 6 in
>>> 2011 Q1), so upgrading to Camel 3.0 isn't possible. Nevertheless when Camel
>>> 3.0 is in development I would still love to see blocking issues being fixed
>>> on the 2.x branch. Changing the major version makes this possible (like you
>>> guys did with the 1.x branch).
>>>
>>> On Tue, Oct 19, 2010 at 2:59 PM, Schneider Christian <
>>> Christian.Schneider@enbw.com> wrote:
>>>
>>>> Hi James,
>>>>
>>>> it is not absolutely necessary to split the jar into three jars. More
>>>> important is to have rules that say that a component developer should only
>>>> depdend on the API part and to check that the internal dependencies do not
>>>> have cycles between the three logical modules. The only disadvantage of not
>>>> breaking up camel core into three modules is that maven will not help you in
>>>> avoiding cycles which would be the case with separate modules. As the rules
>>>> can be checked with tools like structure 101 this is not too bad though.
>>>>
>>>> I don´t think the cyclic depdencies are only a "metric". They are a real
>>>> problem when the code grows as you can not understand or change anything
>>>> isolated. To have three clearly defined parts in camel core that should not
>>>> have cycles between them is quite reasonable imho.
>>>>
>>>> Especially I think the builders should be separated as they are not needed
>>>> at runtime. The builder pattern creates many cycles and it confuses people
>>>> who try to understand the runtime behaviour. Of course I do not speak
>>>> against builders and the dsl. They are extremely convenient and clear to use
>>>> for end users and make a good part of the appeal of camel.
>>>>
>>>> So to sum it up I think breaking up camel-core logically is very important.
>>>> At the same time I understand that ease of use is a value that is probably
>>>> as important as a clear architecture. The good thing is that I am quite sure
>>>> that we can achieve both.
>>>>
>>>> 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: James Strachan [mailto:james.strachan@gmail.com]
>>>> Gesendet: Dienstag, 19. Oktober 2010 14:31
>>>> An: dev@camel.apache.org
>>>> Betreff: Re: Some thoughts about the architecture of camel
>>>>
>>>>
>>>>>
>>>>> So my idea would be to split camel-core into three parts:
>>>>>
>>>>> api, builder, impl
>>>>
>>>> What benefits do you see for end users and component developers having
>>>> to depend on at least 3 jars rather than one?
>>>>
>>>> One of the reasons I like camel-core as it is; its nice and simple and
>>>> just works. You can build & run routes with some simple components
>>>> using the single camel-core jar. (Just add camel-test to do testing).
>>>>
>>>> Sure there's some cyclic package dependencies. Given the large number
>>>> of use cases in Camel (route design, testing, JAXB model, Java DSL and
>>>> base set of components) its kinda hard to totally avoid those while
>>>> having convention over configuration, decent defaults etc.
>>>>
>>>> I value ease of use for end users & component developers and backwards
>>>> compatibility over cyclic dependency metrics any day :)
>>>>
>>>> --
>>>> James
>>>> -------
>>>> http://macstrac.blogspot.com/
>>>>
>>>> Open Source Integration
>>>> http://fusesource.com/
>>>>
>>
>>
>
>
>
> --
> 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: Some thoughts about the architecture of camel
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Oct 19, 2010 at 3:55 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> I think we should take this as a separate discussion. The partial results from the recent survey (which I hope you did fill in)
> show that not many still use java5. Given the problems it causes for the release, I see it as a very good idea to move to jdk6 in camel 2.6. You can still use 2.5 for many months to come, until you decide to upgrade to jdk6, for once, and then we can also have 2.5.x maintenance releases (more rare I hope) for those still interested in using jdk5.
>
Sorry but I think this message will really confuse end users and even our self.
Having Camel 2.x = JDK 1.5 / Spring 2.5 / ( and Spring 3.0 support
from Camel 2.3/4 onwards). Hey even Spring 2.0 is still support I
think.
Now that gets messy if Camel 2.6 is suddenly something else.
Also in the light how we have always done releases at Apache. One
major after the other. 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6 and so forth.
We started maintenance mode of Camel 1.x in the 1.6 line (albeit Camel
1.6.1 should really have been Camel 1.7 since there so many changes in
it.).
It will in fact start to confuse / scare people if Camel 2.5 is
already in the "maintenance mode" and the next expected release would
be Camel 2.5.1.
> I think better is to have a discussion and make a decision regarding jdk5 support after the survey results are final.
>
> Cheers,
> Hadrian
>
>
>
> On Oct 19, 2010, at 9:31 AM, Richard Kettelerij wrote:
>
>> Concerning the 2.0 vs. 3.0 debate. I agree with James and Claus that it
>> would be better to change the major version when you require Spring 3.0 and
>> Java 6.
>>
>> To illustrate, I'm still stuck at Java 5 (we'll probably move to Java 6 in
>> 2011 Q1), so upgrading to Camel 3.0 isn't possible. Nevertheless when Camel
>> 3.0 is in development I would still love to see blocking issues being fixed
>> on the 2.x branch. Changing the major version makes this possible (like you
>> guys did with the 1.x branch).
>>
>> On Tue, Oct 19, 2010 at 2:59 PM, Schneider Christian <
>> Christian.Schneider@enbw.com> wrote:
>>
>>> Hi James,
>>>
>>> it is not absolutely necessary to split the jar into three jars. More
>>> important is to have rules that say that a component developer should only
>>> depdend on the API part and to check that the internal dependencies do not
>>> have cycles between the three logical modules. The only disadvantage of not
>>> breaking up camel core into three modules is that maven will not help you in
>>> avoiding cycles which would be the case with separate modules. As the rules
>>> can be checked with tools like structure 101 this is not too bad though.
>>>
>>> I don´t think the cyclic depdencies are only a "metric". They are a real
>>> problem when the code grows as you can not understand or change anything
>>> isolated. To have three clearly defined parts in camel core that should not
>>> have cycles between them is quite reasonable imho.
>>>
>>> Especially I think the builders should be separated as they are not needed
>>> at runtime. The builder pattern creates many cycles and it confuses people
>>> who try to understand the runtime behaviour. Of course I do not speak
>>> against builders and the dsl. They are extremely convenient and clear to use
>>> for end users and make a good part of the appeal of camel.
>>>
>>> So to sum it up I think breaking up camel-core logically is very important.
>>> At the same time I understand that ease of use is a value that is probably
>>> as important as a clear architecture. The good thing is that I am quite sure
>>> that we can achieve both.
>>>
>>> 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: James Strachan [mailto:james.strachan@gmail.com]
>>> Gesendet: Dienstag, 19. Oktober 2010 14:31
>>> An: dev@camel.apache.org
>>> Betreff: Re: Some thoughts about the architecture of camel
>>>
>>>
>>>>
>>>> So my idea would be to split camel-core into three parts:
>>>>
>>>> api, builder, impl
>>>
>>> What benefits do you see for end users and component developers having
>>> to depend on at least 3 jars rather than one?
>>>
>>> One of the reasons I like camel-core as it is; its nice and simple and
>>> just works. You can build & run routes with some simple components
>>> using the single camel-core jar. (Just add camel-test to do testing).
>>>
>>> Sure there's some cyclic package dependencies. Given the large number
>>> of use cases in Camel (route design, testing, JAXB model, Java DSL and
>>> base set of components) its kinda hard to totally avoid those while
>>> having convention over configuration, decent defaults etc.
>>>
>>> I value ease of use for end users & component developers and backwards
>>> compatibility over cyclic dependency metrics any day :)
>>>
>>> --
>>> James
>>> -------
>>> http://macstrac.blogspot.com/
>>>
>>> Open Source Integration
>>> http://fusesource.com/
>>>
>
>
--
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: Some thoughts about the architecture of camel
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I think we should take this as a separate discussion. The partial results from the recent survey (which I hope you did fill in)
show that not many still use java5. Given the problems it causes for the release, I see it as a very good idea to move to jdk6 in camel 2.6. You can still use 2.5 for many months to come, until you decide to upgrade to jdk6, for once, and then we can also have 2.5.x maintenance releases (more rare I hope) for those still interested in using jdk5.
I think better is to have a discussion and make a decision regarding jdk5 support after the survey results are final.
Cheers,
Hadrian
On Oct 19, 2010, at 9:31 AM, Richard Kettelerij wrote:
> Concerning the 2.0 vs. 3.0 debate. I agree with James and Claus that it
> would be better to change the major version when you require Spring 3.0 and
> Java 6.
>
> To illustrate, I'm still stuck at Java 5 (we'll probably move to Java 6 in
> 2011 Q1), so upgrading to Camel 3.0 isn't possible. Nevertheless when Camel
> 3.0 is in development I would still love to see blocking issues being fixed
> on the 2.x branch. Changing the major version makes this possible (like you
> guys did with the 1.x branch).
>
> On Tue, Oct 19, 2010 at 2:59 PM, Schneider Christian <
> Christian.Schneider@enbw.com> wrote:
>
>> Hi James,
>>
>> it is not absolutely necessary to split the jar into three jars. More
>> important is to have rules that say that a component developer should only
>> depdend on the API part and to check that the internal dependencies do not
>> have cycles between the three logical modules. The only disadvantage of not
>> breaking up camel core into three modules is that maven will not help you in
>> avoiding cycles which would be the case with separate modules. As the rules
>> can be checked with tools like structure 101 this is not too bad though.
>>
>> I don´t think the cyclic depdencies are only a "metric". They are a real
>> problem when the code grows as you can not understand or change anything
>> isolated. To have three clearly defined parts in camel core that should not
>> have cycles between them is quite reasonable imho.
>>
>> Especially I think the builders should be separated as they are not needed
>> at runtime. The builder pattern creates many cycles and it confuses people
>> who try to understand the runtime behaviour. Of course I do not speak
>> against builders and the dsl. They are extremely convenient and clear to use
>> for end users and make a good part of the appeal of camel.
>>
>> So to sum it up I think breaking up camel-core logically is very important.
>> At the same time I understand that ease of use is a value that is probably
>> as important as a clear architecture. The good thing is that I am quite sure
>> that we can achieve both.
>>
>> 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: James Strachan [mailto:james.strachan@gmail.com]
>> Gesendet: Dienstag, 19. Oktober 2010 14:31
>> An: dev@camel.apache.org
>> Betreff: Re: Some thoughts about the architecture of camel
>>
>>
>>>
>>> So my idea would be to split camel-core into three parts:
>>>
>>> api, builder, impl
>>
>> What benefits do you see for end users and component developers having
>> to depend on at least 3 jars rather than one?
>>
>> One of the reasons I like camel-core as it is; its nice and simple and
>> just works. You can build & run routes with some simple components
>> using the single camel-core jar. (Just add camel-test to do testing).
>>
>> Sure there's some cyclic package dependencies. Given the large number
>> of use cases in Camel (route design, testing, JAXB model, Java DSL and
>> base set of components) its kinda hard to totally avoid those while
>> having convention over configuration, decent defaults etc.
>>
>> I value ease of use for end users & component developers and backwards
>> compatibility over cyclic dependency metrics any day :)
>>
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
Re: Some thoughts about the architecture of camel
Posted by Donald Whytock <dw...@gmail.com>.
Something of an outsider here, but I personally would like to see
camel-core broken into smaller pieces for the sake of my OSGi-based
app. At the moment the camel-core .jar is larger than my entire app,
including the felix .jar. I really like the idea of using camel, but
it makes me wince to more than double the size of my deployable
binary. Surely there's something in camel-core that doesn't
absolutely have to be there for simple runtime use?
Don
On Tue, Oct 19, 2010 at 9:31 AM, Richard Kettelerij
<ri...@gmail.com> wrote:
> Concerning the 2.0 vs. 3.0 debate. I agree with James and Claus that it
> would be better to change the major version when you require Spring 3.0 and
> Java 6.
>
> To illustrate, I'm still stuck at Java 5 (we'll probably move to Java 6 in
> 2011 Q1), so upgrading to Camel 3.0 isn't possible. Nevertheless when Camel
> 3.0 is in development I would still love to see blocking issues being fixed
> on the 2.x branch. Changing the major version makes this possible (like you
> guys did with the 1.x branch).
>
> On Tue, Oct 19, 2010 at 2:59 PM, Schneider Christian <
> Christian.Schneider@enbw.com> wrote:
>
>> Hi James,
>>
>> it is not absolutely necessary to split the jar into three jars. More
>> important is to have rules that say that a component developer should only
>> depdend on the API part and to check that the internal dependencies do not
>> have cycles between the three logical modules. The only disadvantage of not
>> breaking up camel core into three modules is that maven will not help you in
>> avoiding cycles which would be the case with separate modules. As the rules
>> can be checked with tools like structure 101 this is not too bad though.
>>
>> I don´t think the cyclic depdencies are only a "metric". They are a real
>> problem when the code grows as you can not understand or change anything
>> isolated. To have three clearly defined parts in camel core that should not
>> have cycles between them is quite reasonable imho.
>>
>> Especially I think the builders should be separated as they are not needed
>> at runtime. The builder pattern creates many cycles and it confuses people
>> who try to understand the runtime behaviour. Of course I do not speak
>> against builders and the dsl. They are extremely convenient and clear to use
>> for end users and make a good part of the appeal of camel.
>>
>> So to sum it up I think breaking up camel-core logically is very important.
>> At the same time I understand that ease of use is a value that is probably
>> as important as a clear architecture. The good thing is that I am quite sure
>> that we can achieve both.
>>
>> 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: James Strachan [mailto:james.strachan@gmail.com]
>> Gesendet: Dienstag, 19. Oktober 2010 14:31
>> An: dev@camel.apache.org
>> Betreff: Re: Some thoughts about the architecture of camel
>>
>>
>> >
>> > So my idea would be to split camel-core into three parts:
>> >
>> > api, builder, impl
>>
>> What benefits do you see for end users and component developers having
>> to depend on at least 3 jars rather than one?
>>
>> One of the reasons I like camel-core as it is; its nice and simple and
>> just works. You can build & run routes with some simple components
>> using the single camel-core jar. (Just add camel-test to do testing).
>>
>> Sure there's some cyclic package dependencies. Given the large number
>> of use cases in Camel (route design, testing, JAXB model, Java DSL and
>> base set of components) its kinda hard to totally avoid those while
>> having convention over configuration, decent defaults etc.
>>
>> I value ease of use for end users & component developers and backwards
>> compatibility over cyclic dependency metrics any day :)
>>
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
>
Re: Some thoughts about the architecture of camel
Posted by Richard Kettelerij <ri...@gmail.com>.
Concerning the 2.0 vs. 3.0 debate. I agree with James and Claus that it
would be better to change the major version when you require Spring 3.0 and
Java 6.
To illustrate, I'm still stuck at Java 5 (we'll probably move to Java 6 in
2011 Q1), so upgrading to Camel 3.0 isn't possible. Nevertheless when Camel
3.0 is in development I would still love to see blocking issues being fixed
on the 2.x branch. Changing the major version makes this possible (like you
guys did with the 1.x branch).
On Tue, Oct 19, 2010 at 2:59 PM, Schneider Christian <
Christian.Schneider@enbw.com> wrote:
> Hi James,
>
> it is not absolutely necessary to split the jar into three jars. More
> important is to have rules that say that a component developer should only
> depdend on the API part and to check that the internal dependencies do not
> have cycles between the three logical modules. The only disadvantage of not
> breaking up camel core into three modules is that maven will not help you in
> avoiding cycles which would be the case with separate modules. As the rules
> can be checked with tools like structure 101 this is not too bad though.
>
> I don´t think the cyclic depdencies are only a "metric". They are a real
> problem when the code grows as you can not understand or change anything
> isolated. To have three clearly defined parts in camel core that should not
> have cycles between them is quite reasonable imho.
>
> Especially I think the builders should be separated as they are not needed
> at runtime. The builder pattern creates many cycles and it confuses people
> who try to understand the runtime behaviour. Of course I do not speak
> against builders and the dsl. They are extremely convenient and clear to use
> for end users and make a good part of the appeal of camel.
>
> So to sum it up I think breaking up camel-core logically is very important.
> At the same time I understand that ease of use is a value that is probably
> as important as a clear architecture. The good thing is that I am quite sure
> that we can achieve both.
>
> 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: James Strachan [mailto:james.strachan@gmail.com]
> Gesendet: Dienstag, 19. Oktober 2010 14:31
> An: dev@camel.apache.org
> Betreff: Re: Some thoughts about the architecture of camel
>
>
> >
> > So my idea would be to split camel-core into three parts:
> >
> > api, builder, impl
>
> What benefits do you see for end users and component developers having
> to depend on at least 3 jars rather than one?
>
> One of the reasons I like camel-core as it is; its nice and simple and
> just works. You can build & run routes with some simple components
> using the single camel-core jar. (Just add camel-test to do testing).
>
> Sure there's some cyclic package dependencies. Given the large number
> of use cases in Camel (route design, testing, JAXB model, Java DSL and
> base set of components) its kinda hard to totally avoid those while
> having convention over configuration, decent defaults etc.
>
> I value ease of use for end users & component developers and backwards
> compatibility over cyclic dependency metrics any day :)
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
Re: Some thoughts about the architecture of camel
Posted by Christian Schneider <ch...@die-schneider.net>.
I think I used runtime in the wrong context. What I meant is that you
only need the builders when you set up a route. Then while it runs you
don´t need it anymore.
A component implementation should have no knowledge about the dsl that
created it. The advantage is then that the dsl can be changed without
touching the component.
That is why I think a component should only depend on some kind of api
part of camel core.
Also when the user creates his own processor then inside this
implementation he should not know about builders. He should be able to
introspect the existing but I don´t think he needs to change it at that
time.
Best Regards
Christian
Am 19.10.2010 15:22, schrieb James Strachan:
> On 19 October 2010 13:59, Schneider Christian
> <Ch...@enbw.com> wrote:
>> Hi James,
>>
>> it is not absolutely necessary to split the jar into three jars. More important is to have rules that say that a component developer should only depdend on the API part and to check that the internal dependencies do not have cycles between the three logical modules. The only disadvantage of not breaking up camel core into three modules is that maven will not help you in avoiding cycles which would be the case with separate modules. As the rules can be checked with tools like structure 101 this is not too bad though.
>>
>> I don´t think the cyclic depdencies are only a "metric". They are a real problem when the code grows as you can not understand or change anything isolated. To have three clearly defined parts in camel core that should not have cycles between them is quite reasonable imho.
>>
>> Especially I think the builders should be separated as they are not needed at runtime.
> I don't follow this comment. When would the builders and DSL be used
> other than at runtime? Every use case I've seen of the builders and
> DSLs is for runtime stuff; defining routes at runtime; often using
> runtime dependency injection.
>
--
----
http://www.liquid-reality.de
Re: Some thoughts about the architecture of camel
Posted by James Strachan <ja...@gmail.com>.
On 19 October 2010 13:59, Schneider Christian
<Ch...@enbw.com> wrote:
> Hi James,
>
> it is not absolutely necessary to split the jar into three jars. More important is to have rules that say that a component developer should only depdend on the API part and to check that the internal dependencies do not have cycles between the three logical modules. The only disadvantage of not breaking up camel core into three modules is that maven will not help you in avoiding cycles which would be the case with separate modules. As the rules can be checked with tools like structure 101 this is not too bad though.
>
> I don´t think the cyclic depdencies are only a "metric". They are a real problem when the code grows as you can not understand or change anything isolated. To have three clearly defined parts in camel core that should not have cycles between them is quite reasonable imho.
>
> Especially I think the builders should be separated as they are not needed at runtime.
I don't follow this comment. When would the builders and DSL be used
other than at runtime? Every use case I've seen of the builders and
DSLs is for runtime stuff; defining routes at runtime; often using
runtime dependency injection.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
AW: Some thoughts about the architecture of camel
Posted by Schneider Christian <Ch...@enbw.com>.
Hi James,
it is not absolutely necessary to split the jar into three jars. More important is to have rules that say that a component developer should only depdend on the API part and to check that the internal dependencies do not have cycles between the three logical modules. The only disadvantage of not breaking up camel core into three modules is that maven will not help you in avoiding cycles which would be the case with separate modules. As the rules can be checked with tools like structure 101 this is not too bad though.
I don´t think the cyclic depdencies are only a "metric". They are a real problem when the code grows as you can not understand or change anything isolated. To have three clearly defined parts in camel core that should not have cycles between them is quite reasonable imho.
Especially I think the builders should be separated as they are not needed at runtime. The builder pattern creates many cycles and it confuses people who try to understand the runtime behaviour. Of course I do not speak against builders and the dsl. They are extremely convenient and clear to use for end users and make a good part of the appeal of camel.
So to sum it up I think breaking up camel-core logically is very important. At the same time I understand that ease of use is a value that is probably as important as a clear architecture. The good thing is that I am quite sure that we can achieve both.
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: James Strachan [mailto:james.strachan@gmail.com]
Gesendet: Dienstag, 19. Oktober 2010 14:31
An: dev@camel.apache.org
Betreff: Re: Some thoughts about the architecture of camel
>
> So my idea would be to split camel-core into three parts:
>
> api, builder, impl
What benefits do you see for end users and component developers having
to depend on at least 3 jars rather than one?
One of the reasons I like camel-core as it is; its nice and simple and
just works. You can build & run routes with some simple components
using the single camel-core jar. (Just add camel-test to do testing).
Sure there's some cyclic package dependencies. Given the large number
of use cases in Camel (route design, testing, JAXB model, Java DSL and
base set of components) its kinda hard to totally avoid those while
having convention over configuration, decent defaults etc.
I value ease of use for end users & component developers and backwards
compatibility over cyclic dependency metrics any day :)
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: Some thoughts about the architecture of camel
Posted by James Strachan <ja...@gmail.com>.
On 18 October 2010 10:43, Schneider Christian
<Ch...@enbw.com> 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
What benefits do you see for end users and component developers having
to depend on at least 3 jars rather than one?
One of the reasons I like camel-core as it is; its nice and simple and
just works. You can build & run routes with some simple components
using the single camel-core jar. (Just add camel-test to do testing).
Sure there's some cyclic package dependencies. Given the large number
of use cases in Camel (route design, testing, JAXB model, Java DSL and
base set of components) its kinda hard to totally avoid those while
having convention over configuration, decent defaults etc.
I value ease of use for end users & component developers and backwards
compatibility over cyclic dependency metrics any day :)
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/