Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.212.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=T/ef9CcAkgHIbztr4uaOb95Ra2r4s9IRDNkVfpwfSGji52FUxywkhs72Pl0Cz8Wwo9
         UrRZn7SuA1gKBVm+WuCnA9WSzBjEBX3OiZYuQ39nCpExVVOxM7OxixQiqZpUQ3YfMHkc
         By95+vQdlf1vCLY1DbsraZLu+YgUIQU3GrZZk=
MIME-Version: 1.0
In-Reply-To: <0E608B3AEB71BF429396A5AF065ED05D09DB2986D8@S3Q2173.enbw.net>
References: <0E608B3AEB71BF429396A5AF065ED05D09DB2986CD@S3Q2173.enbw.net>
 <2AAB14A1-A61F-4636-864D-278B00D21F10@gmail.com>
 <AANLkTimhRue6SGeaK6RNGcGUm_ejaCBYR=BiXOuqzWwK@mail.gmail.com>
 <201010190747.23990.dkulp@apache.org>
 <AANLkTinM8wcsRBqFvS-0UNTPp4bXE2nCVof6QrNiFXFs@mail.gmail.com>
 <0E608B3AEB71BF429396A5AF065ED05D09DB2986D8@S3Q2173.enbw.net>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Tue, 19 Oct 2010 15:44:23 +0200
Message-ID: <AANLkTi=q3Yidh19wFAUjVteuCH9wmBiLZSJeL4w9fUUk@mail.gmail.com>
Subject: Re: [DISCUSS] Some thoughts about the architecture of camel
To: dev@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 19, 2010 at 2:26 PM, Schneider Christian
<Christian.Schneider@enbw.com> wrote:
> If you consider spring and jdk a (somewhat) breaking change then a 3.0 ve=
rsion is the right thing of course. I don=B4t care too much if this version=
 is called 2.6 or 3.0 ;-)
>
> In this case I would like to have the more advanced stuff in the 4.0 vers=
ion. Do you think that is possible?
>

Yeah definitely. We all know that at some time the current
architecture needs change and a new major version such as 4.0 is a
good version to do that. Then we also have longer time to work on it,
and people on the current 2.x/3.x architecture can rest assured the
API stays compatible so their components and other 3rd party projects
integrating out of the box with Camel, still works as is.

And maybe at Camel 4, we got goodies from JDK7 we can leverage (NIO2,
ForkJoin) or there are some great other frameworks out there we can
let Camel depend upon.

Or maybe even the Scala stuff just good so compelling that we all got
hooked and rewrote camel-core in Scala.


> Best Regards
>
> 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 =AD HRB 108550
> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
> Gesch=E4ftsf=FChrer: Jochen Adenau, Hans-G=FCnther Meier
>
>
> -----Urspr=FCngliche Nachricht-----
> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
> Gesendet: Dienstag, 19. Oktober 2010 14:22
> An: dev@camel.apache.org
> Betreff: Re: [DISCUSS] Some thoughts about the architecture of camel
>
> On Tue, Oct 19, 2010 at 1:47 PM, Daniel Kulp <dkulp@apache.org> wrote:
>> 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 param=
ount
>>
>> Umm.. =A0Everything listed there could go into a 2.6 release. =A0 I don'=
t see any
>> reason for that to be what defines a 3.0 release.
>>
>
> Sorry but those changes are major. Changing the minimum supported JDK
> platform is.
> eg Spring 2.5 still supports JDK 1.4. Only Spring 3.0 is JDK 1.5+ only.
>
> We can't just change that mid stream.
>
> And we dont du usually do so many minor releases as you do with CXF,
> eg 2.2.1 -> 2.2.11
> At Camel we do 2.0, 2.1, 2.2, 2.3 etc.
>
>
>> 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 t=
he
>> API's and feature that are requried for the various new and exciting ide=
as
>> people are proposing.
>>
>
> Sorry but I think the community want an easy upgrade path for JDK 1.6
> / Spring 3.0 based on the current 2.x architecture.
>
> It works really well, easy to write custom components. Hence why we
> got so many now.
> And many 3rd party projects have integrated out of the box with Camel.
> And we would lose some if we keep changing the architecture.
>
> We should not do a "Tapestry" with the Camel project, and change the
> core at each major release.
>
>
>> 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> w=
rote:
>>> > 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 no=
t 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+-+Roa=
dmap
>>> >
>>> > 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 fo=
r
>>> >> 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 wo=
rk.
>>> >>
>>> >> As you surely know currently camel-core is quite tangled. So it is q=
uite
>>> >> difficult where to start. Some time ago I proposed some improvements=
 to
>>> >> simply reduce those dependency cycles. As I now know a lot more abou=
t
>>> >> 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 thing=
s
>>> >> 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 t=
he
>>> >> components should use and which classes should be private to core. E=
ven
>>> >> classes from the impl package are needed. So this means that any
>>> >> refactoring we do in camel core could affect all components. As came=
l
>>> >> 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 d=
o
>>> >> not have cyclic dependencies. Any other cycles can be ignored in thi=
s
>>> >> 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 conse=
nsus
>>> >> about a basic architecure and rules like above. Then the next step i=
s
>>> >> to assign each package of core to one of the basic parts. Then the n=
ext
>>> >> 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=E4ftsf=FChrer: Jochen Adenau, Hans-G=FCnther Meier
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>
>
>
> --
> 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
>


--=20
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