camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen">
Subject RE: Deprecating old methods and changing the default error handler
Date Fri, 20 Jun 2008 04:21:29 GMT
Hi Gert

Great insight. And sorry about the problems with the API breakings. We should target all the
"fix the tangle etc." tickets to Camel 2.0, so there wont be another API breaking.

+1 for that one

Do you have a list at hand what the API breaking were between 1.3 and 1.4? We should at least
document this in the release note that there can be API breakings.

+1 of course for the dead letter channel as well. We cant have them being retried 6 times
within 1 sec. Interval and then just stoved away in a log ;)

Maybe somekind of INFO/WARN level when the route context is created/started that the DLC is
NoErrorHandler so end users will notice that they might haven't thought/set a error handling
strategy fitting to their needs.

Med venlig hilsen
Claus Ibsen
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
-----Original Message-----
From: Gert Vanthienen [] 
Sent: 19. juni 2008 08:40
Subject: Deprecating old methods and changing the default error handler


While I was doing a project with a customer last week, I ran into a few 
problems with using Camel for them.

First problem were changes in the API (e.g. Endpoint.getContext() 
becomes Endpoint.getCamelContext()).  I needed to rebuild 
servicemix-camel to get some fixes there, but along came a new version 
of Camel and that was breaking a lot of the existing code.  We might 
want to consider deprecating the old methods instead of removing them.  
Not entirely sure about this though: it will probably slow us down a 
bit, but on the other hand, when a user updates from 1.3 to 1.4 he 
probably doesn't expect API breakage of this type.  They would expect 
this to happen from a major release though (Camel 2.0), so I would 
suggest cleaning up all deprecated code at that point.  Wdyt?

A second thing that kind surprises people is our implicit use of a dead 
letter channel in every RouteBuilder.  Let me give an example:
public class MyRouteBuilder extends RouteBuilder {
  public void configure() {

If you look at the code above, it appears to be routing from one JBI 
endpoint to the next one, without doing anything else.  Now, in reality, 
if something goes wrong at the second endpoint (e.g. FTP server goes 
down), the default DeadLetterChannel kicks in and after 5 retries, it 
will "log away" the message.  The first JBI component will never know 
something went wrong, because the JBI Exchange going back will just say 
DONE and the only trace of something going wrong is in the logs -- the 
message itself was lost in the process.  We should at the very least 
warn people to explicitly set an errorHandler() when using Camel inside 
Servicemix (usually just errorHandler(noErrorHandler()), but actually I 
don't think we should make this behavior the default.  It might be good 
for testing/demos, but in real life you probably want to specify a more 
advanced error handling routine or let the underlying system (e.g. 
ServiceMix) take care of it.  In my mind, we should seriously consider 
making no error handler the default for Camel 2.0.  Once again: wdyt?



View raw message