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 <[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 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
