Hi, +1 I like all the ideas.
Besides, CAMEL-10627 <https://issues.apache.org/jira/browse/CAMEL-10627> may also be linked to this issue and also more advanced features CAMEL-11275 <https://issues.apache.org/jira/browse/CAMEL-11275> or CAMEL-8599 <https://issues.apache.org/jira/browse/CAMEL-8599> mentioned here like routes depending on each other could be good implementation where also SPI API would beneficial for whom wants to implement their own logic. For endpoint configuration reload and route reloads may be considered together. +1 for all. Very nice features i believe and like to help them. On Mon, Jul 17, 2017 at 2:23 PM, Luca Burgazzoli <[email protected]> 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 >
