camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bvahdat <>
Subject Re: Riding on org.apache.camel.language.TokenPairPredicateTest
Date Mon, 05 Dec 2011 14:44:39 GMT

The fix you provided indeed did mitigated the issue I had on Windows
(TokenPairPredicateTest now passes as well), however my viewpoint as I
shared in [1] is still pending. Effectively what I would expect to have in
LoggingExceptionHandler is the code below, which *per default* rethrows the
exception after it logs it. However making that change in my workspace (of
course) now causes side effects by other unit-tests to fail. So I assume to
fix LoggingExceptionHandler *to not just swallow* the thrown exceptions will
be not that trivial!

Just as an example imagine a simple billing-system having a single camel
context with two routes in it. One route produces the monthly bills and dump
them into a xml-file (using the file producer), the other one reads that
xml-file (through the file consumer), splits the bill-entries and send the
bills to the consumers by mail. Now with that exception swalling behaviour
of LoggingExceptionHandler in place, if generating/renaming/moving of the
xml-file by the first route fails in between, for example just because of
the possible:

- disk out of space issue
- maximum unix quota has been already reached issue 

Then the second route would wait & wait & wait forever and there will be not
even an invocation of possible onException clause (if any) at all. So the
operation guys will not realize any problem (not even through JMX or
whatnot)...So happy free-service for the customers...

How do you see this? Am I missing something?



public class LoggingExceptionHandler implements ExceptionHandler {
    private final CamelLogger logger;
    private final boolean rethrowException;

    public LoggingExceptionHandler(Class<?> ownerType) {
        this(new CamelLogger(LoggerFactory.getLogger(ownerType)), true);

    public LoggingExceptionHandler(Class<?> ownerType, LoggingLevel level) {
        this(new CamelLogger(LoggerFactory.getLogger(ownerType), level),

    public LoggingExceptionHandler(Class<?> ownerType, boolean
rethrowException) {
        this(new CamelLogger(LoggerFactory.getLogger(ownerType),
LoggingLevel.ERROR), rethrowException);

    public LoggingExceptionHandler(Class<?> ownerType, LoggingLevel level,
boolean rethrowException) {
        this(new CamelLogger(LoggerFactory.getLogger(ownerType), level),

    public LoggingExceptionHandler(CamelLogger logger, boolean
rethrowException) {
        this.logger = logger;
        this.rethrowException = rethrowException;

    public void handleException(Throwable exception) {
        handleException(null, null, exception);

    public void handleException(String message, Throwable exception) {
        handleException(message, null, exception);

    public void handleException(String message, Exchange exchange, Throwable
exception) {
        try {
            String msg =
CamelExchangeException.createExceptionMessage(message, exchange, exception);
            if (isCausedByRollbackExchangeException(exception)) {
                // do not log stacktrace for intended rollbacks
            } else {
                logger.log(msg, exception);
        } catch (Throwable e) {
            // the logging exception handler must not cause new exceptions
to occur

        // rethrow the exception (wrapped by RuntimeCamelException) if we're
asked to do so
        if (rethrowException) {
            throw ObjectHelper.wrapRuntimeCamelException(exception);

    protected boolean isCausedByRollbackExchangeException(Throwable
exception) {
        if (exception instanceof RollbackExchangeException) {
            return true;
        } else if (exception.getCause() != null) {
            // recursive children

        return false;

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message