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.ib...@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 <lburgazz...@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
