On Tue, Oct 19, 2010 at 6:40 AM, Johan Edstrom <[email protected]> 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 <[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 >>>> >>>> >>>> >>> >>> >> >> >> >> -- >> 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 > > [email protected] > > 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
