camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Burgazzoli <lburgazz...@gmail.com>
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 <claus.ibsen@gmail.com> 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 <lburgazzoli@gmail.com> 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
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Mime
View raw message