On Tue, Oct 19, 2010 at 6:58 AM, Martin Krasser <[email protected]> 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<[email protected]> >> 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
