I'm interested in this too! I'm here to help. On Feb 19, 2013, at 3:44 PM, Christian Müller <christian.muel...@gmail.com> wrote:
> 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 >>>> >>>> >>> >>> >>> > > > --
