camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Burgazzoli <>
Subject Re: Camel 3.0 : make default camel context "modular"
Date Wed, 19 Jul 2017 07:37:53 GMT
It is still quite risky now too :)

That's why I just implemented a very tiny RouteController. I Was too
scared to eventually introduce nasty an unpredictable regression.

Thinking aloud: we may have a "reactive" change so the route loader is
a subscriber of the reload strategy so when the strategy emits a
signal,  the loader does its job asynchronously and we can put some
intermediate steps like throttling the changes so that only the last
one get taken into account.

Luca Burgazzoli

On Wed, Jul 19, 2017 at 9:10 AM, Claus Ibsen <> wrote:
> 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