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
