camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Camel 3.0 : make default camel context "modular"
Date Wed, 19 Jul 2017 07:10:21 GMT
Hi Luca

Yes sounds like good ideas.

I do agree that the loading/startup of routes logic in
DefaultCamelContext would have benefitted from being refactored many
years ago, but then doing bigger refactoring in such a core
functionality was also a bit "risky". The notion of a RouteLoader is a
good idea, there is also the ReloadStrategy which we should think
about how that may work with the RouteLoader and how it can watch some
external system for changes and then trigger a reload.

On Mon, Jul 17, 2017 at 1:23 PM, Luca Burgazzoli <> wrote:
> Hello devs,
> not sure if it make sense for everyone but after working a little bit on
> the default camel context for CAMEL-11443 I think we should try to break
> it into logical components to make it easy to evolve and improve it so
> for camel 3.0 I was thinking something like:
> - Add a concept of RouteLoader which is in charge of building the route
>   definitions from a source, to eventually monitor the source for
>   changes and then refresh the contex so i.e. we can move the current
>   process of loading routes from xml to a dedicated XMLRouteLoader. It
>   should be possible to add more loaders so one can load routes from
>   different sources (yaml, json, groovy)
> - Add a concept of RouteControler which is in charge of routes'
>   life-cycle, this is partially done by CAMEL-11443 but for 2.x it will
>   be more a placeholder that an concrete implementation as the
>   life-cycle of routes involves quite a bit of code and it is quite hard
>   to introduce a proper life-cycle manager without breaking the things.
>   In my mind the camel context should be a bridge between RouteLoader
>   and the RouteController then the specific route controller can do its
>   job like:
>   - start routes in parallel
>   - handle reoutes dependencies (CAMEL-8599)
>   - restart failing routes
>   - etc
> - Have a single and complete source fo events, as today we can listen
>   for events using different concepts:
>   - LifecycleStrategy
>   - StartupListener
>   - EventNotifier
>   - RoutePolicy
>   Some of them seems overlapping a little so we may create 'contextual'
>   listeners like RouteEventListener, ExchangeEventListener, etc and
>   then i.e. the RoutePolicy could extend only what make sense for the
>   context so for the camel context prospective only an event has to be
>   fired. Listeenrs can eventually throw an uncheckd "VetoedException"
>   if the operation should not be done (i.e. a policy may prevent to
>   stop or start a route if certain circumstances).
> I know it is not a simple task but I think it is wort at least try to
> do it.
> Thoughts ?
> ---
> Luca Burgazzoli

Claus Ibsen
----------------- @davsclaus
Camel in Action 2:

View raw message