camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: [DISCUSS] Some thoughts about the architecture of camel
Date Tue, 19 Oct 2010 11:47:23 GMT
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 <hzbarcea@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

Mime
View raw message