Hadrian, did you found time to work on the new Camel components test kit? Should we plan a coding session in Portland?
Best, Christian On Tue, Feb 19, 2013 at 8:34 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: > Comments inline. > Cheers, > Hadrian > > > On 02/19/2013 01:09 PM, Claus Ibsen wrote: > >> On Tue, Feb 19, 2013 at 11:04 AM, Christian Schneider >> <ch...@die-schneider.net> wrote: >> >>> Hi Claus, >>> >>> do you think it is possible to refactor camel core in this way (to >>> implement a real routing engine)? After the refactorings I already did I >>> am not sure it would work. >>> >>> >> Yes it is possible. The main switch is to use a runtime iterator based >> model, that decides at runtime >> which next processor to invoke. Instead of the current "static" approach. >> > > I know for a fact that it's much more complicated than that and I am more > with Christian on that. While I think it's possible, it's far, far from > just an iterator. > > > >> >> Another aproach instead of refactoring would be to first define a new >>> really slim API for components and implement it using the current >>> camel-core. >>> Then we would change each component to use the new API. When all >>> components are switched it will be much easier to change the core as we >>> do not have to >>> refactor all components to make the build work again. We discussed this >>> idea at last Apachecon with Guillaume, Christian Müller and Charles. >>> Then it was mainly in the light of having a small self contained API but >>> I think it would also help with the routing engine. >>> >>> >> The change in the routing engine should be internal facing only, and >> all the tests should ideally pass. >> There may be a few gremlins in the tests that has some internal >> assumptions. But any end user scenario >> of unit tests should have the goal of pass as is. To ensure backwards >> compatability. >> > Agree that the routing engine should be a change internal to the runtime. > The tests we have are not unit tests and in principle I agree with the goal > of them passing as is after the refactoring. However I believe that with > the tests in the current shape it will be cost (time/energy) prohibitive to > refactor the core. > > > >> So there is no need to change any unit tests. Also the unit tests we >> have today serve as good use-cases >> for people to understand how to use Camel and its routes / components. >> > > Actually in my opinion changing the tests is an absolutee must for 3.0 to > have a chance of being more than lipstick. If we give that up, we'll give > up refactoring the api as well. That's what my crystal globe tells me. > > > > >> >> >> Christian >>> >>> On 19.02.2013 10:31, Claus Ibsen wrote: >>> >>>> >>>> Its been on the Camel 3.0 roadmap for a long time >>>> >>>> Though its heading caption may have been chosen a better wording than >>>> - More flexible routes at runtime >>>> http://camel.apache.org/camel-**30-ideas.html<http://camel.apache.org/camel-30-ideas.html> >>>> >>>> We had it as target for a long time, but as you said it safter to work >>>> on this in a major release than on the 2.x architecture. >>>> And hence why its not been done yet. >>>> >>>> And in term of the model, then we have missing pieces about the >>>> inteceptors/onExceptions and whatnot. This is also on the roadmap for >>>> Camel 3.0 >>>> - Add OnException, Interceptor, etc. to JAXB model for a >>>> CamelContextDefinition >>>> >>>> >>>> >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> http://www.talend.com >>> >>> >> >> >> --
