Hi Willem, I was aware of the ExchangeFormatterRef option. With that it is possible to set that Option on the default error handler, but just in order to set the maximum number of characters it seems like a bit of overkill to me.
I would propose the following order: 1. If the maxChars parameter on the DefaultExchangeParameter is set, that value is taken. 2. If the maxChars parameter is not explicitly set, but the Exchange.LOG_DEBUG_BODY_MAX_CHARS property is set, that value is used. 3. If neither parameter or propery is set, the old default of 10000 characters applies. Do you think this is fine? This change would only change the current behavior if the Exchange. LOG_DEBUG_BODY_MAX_CHARS property is set and no maxChars parameter is given (and I would guess that using that body length for all log statements should not be a surprising behavior for the user). Best regards Stephan -----Original Message----- From: Willem Jiang [mailto:[email protected]] Sent: Freitag, 28. November 2014 06:28 To: [email protected] Subject: Re: Somewhat inconsistent behaviour for message logging We introduce a ExchangeFormatterRef option to RedeliveryErrorHandler[1] since Camel 2.15.0, it should be more easy for us setup ExchangeFormatter for the ErrorHandler. But It could more easy for us to manage the max chars option by set up the properties through the camel context. Please feel free to create a JIRA and submit your patch :) [1]https://issues.apache.org/jira/browse/CAMEL-7951 [2]https://issues.apache.org/jira/browse/CAMEL -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On November 27, 2014 at 9:35:28 PM, Siano, Stephan ([email protected]) wrote: > Hi, > > I have looked into the coding for the logging of the payload in different > locations of > the Camel coding, but it looks somewhat inconsistent to me. > > In several places MessageHelper.extractBodyForLogging(Message) or > MessageHelper.extractBodyForLogging(Message, > String) is used to get a payload formatted for logging (e.g. in the > DefaultMessage.toString() > method). In that case the logged message body will be truncated to the length > of the Exchange.LOG_DEBUG_BODY_MAX_CHARS > exchange property or to 1000 characters if this is not set. > > The DefaultExchangeFormatter (that is e.g. used in the log endpoint and the > DefaultErrorHandler) > has a setter for maxChars and uses the value set there or a default of 10000 > characters > when calling the MessageHelper.extractBodyForLogging(Message, String, > boolean, > boolean, int) method. IMO this makes some sense for the log endpoint, where > the maxChars > parameter of the DefaultExchangeFormatter is set from the endpoint parameter, > but > it makes it very hard to properly configure this for the DefaultErrorHandler. > > Is this desired? > > Wouldn't it be better if the DefaultExchangeFormatter would also honor the > Exchange.LOG_DEBUG_BODY_MAX_CHARS? > > The question would be what would take precedence, the parameter or the > property in case > both are set. > > If this makes sense, I could provide an extension to the > DefaultExchangeFormatter for > this. > > Best regards > Stephan >
