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
>
>
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
