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 <[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 -- Daniel Kulp [email protected] http://dankulp.com/blog
