Raul you have huge +1 from me on this idea. Basically I was thinking about idea of "logical" modules for Camel 3.0 which could modify routing chain, property configurations. Overall purpose is to get rid from core all magic which was built around PropertiesComponent/TraceInterceptor and so on (don't know why it still remains in core). I can't easily count how many instanceof statements we have in code.
The "module" thing came to me after using Jackson 2.0. An example module which enables Hibernate integration can be found on github [1]. [1] https://github.com/FasterXML/jackson-module-hibernate Kind regards, Łukasz Dywicki -- l...@code-house.org Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org Wiadomość napisana przez Christian Schneider <ch...@die-schneider.net> w dniu 19 lut 2013, o godz. 08:20: > +1 > > I think one of the main things camel is missing is a routing engine. > Like you wrote, currently each processor calls the next. Aspects like > asynchronous behaviour, transaction and security are also > implemented as processors. > > I think what we need is a runtime model of a camel route that represents > the route without aspects. The aspects should then be executed > by the routing engine without blowing up this model. > > This change is pretty severe though. I am not sure if we can refactor > the camel core and keep it even somewhat compatible. > I also fear that once we start these changes there is no way back and we > might risk having an instable branch for a long time. So we have > to reduce this risk in some way. > > Christian > > On 19.02.2013 01:21, Raul Kripalani wrote: >> Hello team, >> >> We use a recursive model in our routing engine to chain processors with one >> another to process exchanges. >> >> This results in lengthy stacktraces and increased memory usage due to local >> variable retention for longer than strictly needed, IMHO. This recent >> question on Stack Overflow is a typical (short!) stacktrace: >> http://stackoverflow.com/questions/14734983/camel-ftp-intermittent-issue. >> Debugging >> it can be daunting for users. >> >> Moreover many infrastructural Processors are woven implicitly along the >> processor chain. Maybe this logic should belong elsewhere (the routing core >> itself?). >> >> Now that the Camel routing model is consolidated, can we start thinking >> about moving towards an iterative routing approach? I feel the recursive >> approach worked wonders when Camel was still a baby and the architecture >> was heavily evolving: basically any processor, at any point, could do >> anything to the exchange. And everything was a processor. Flexible and >> versatile! >> >> But now that the concepts are well rooted, I feel we need to formally >> define "the routing process", rather than leaving it all up to processors >> to be assembled in the right order. >> >> I realize my proposal may sound somewhat abstract at this point, but before >> going to further length, I want to gauge if my concern is shared. >> >> What do you think? >> >> Raúl. >> > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
