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
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
