L.S.,
Added https://issues.apache.org/activemq/browse/CAMEL-629 to re-add the
old getContext/setContext methods and deprecate them instead of removing
them
Gert
James Strachan wrote:
Sounds good on both counts!
2008/6/19 Gert Vanthienen <[EMAIL PROTECTED]>:
L.S.,
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() {
from("jbi:endpoint:urn:ns:service:endpoint1").to("jbi:endpoint:urn:ns:service:endpoint2");
}
}
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?
Regards,
Gert
