Mailing-List: contact camel-dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-dev@activemq.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Deprecating old methods and changing the default error handler
Date: Fri, 20 Jun 2008 06:21:29 +0200
Message-ID: <4C1FB9C00D24A140906239533638C4D204802B00@EXVS04.exserver.dk>
In-Reply-To: <4859FF5D.8060809@skynet.be>
Thread-Topic: Deprecating old methods and changing the default error handler
Thread-Index: AcjR1zn/K78RE0hSQS+DKDYjDyN39gAtSv6Q
From: "Claus Ibsen" <ci@silverbullet.dk>
To: <camel-dev@activemq.apache.org>

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
=20
Claus Ibsen
......................................
Silverbullet
Skovsg=E5rdsv=E6nget 21
8362 H=F8rning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: Gert Vanthienen [mailto:gert.vanthienen@skynet.be]=20
Sent: 19. juni 2008 08:40
To: camel-dev@activemq.apache.org
Subject: Deprecating old methods and changing the default error handler

L.S.,


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

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

A second thing that kind surprises people is our implicit use of a dead=20
letter channel in every RouteBuilder.  Let me give an example:
public class MyRouteBuilder extends RouteBuilder {
  public void configure() {
   =20
from("jbi:endpoint:urn:ns:service:endpoint1").to("jbi:endpoint:urn:ns:ser=
vice:endpoint2");
  }
}

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


Regards,

Gert