Hi Just a heads up that I have just pushed a bigger work to completely separate the model + reifier from the runtime processor.
After Camel has been bootstrapped and all routes initialized and whatelse, then CamelContext will automatic cleanup various bits which allows to decouple model + reifier from the runtime routes. Which means the left over objects can be GC and classes unloaded. There is a new lightweight mode you can turn on, that goes even further and "locks" camel with current set of routes, that allows even more to be unloaded. On Wed, Nov 4, 2020 at 3:40 PM Claus Ibsen <claus.ib...@gmail.com> wrote: > > Hi > > Just a heads up that in Camel 3.7 we have separated this. I wrote a > blog post with some of the benefits this bring to the table > http://www.davsclaus.com/2020/11/apache-camel-37-more-camel-core.html > > There is one last remainder which is error handlers that are stored on > the DefaultRoute and the Multicast / Splitter EIP uses this to create > error handling for the messages that it "sends out". > > It would be good to get that separated as well, which then would mean > we have a way to totally separate the "build time / design time" of > Camel routes vs runtime processors. And as such then all the classes > from camel-core-model and camel-core-reifier would not be needed > thereafter. > > The consequence is that the CamelContext then becomes "static" in > terms of adding new routes, which no longer would be possible as the > model/reifiers are gone. However this fits the trend with > microservices / serverless / functions etc so its a great step for > Camel to make itself great for this. > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
