Hi, I have created https://issues.apache.org/jira/browse/CAMEL-8091 for this issue and attached a patch.
Best regards Stephan -----Original Message----- From: Siano, Stephan [mailto:stephan.si...@sap.com] Sent: Freitag, 28. November 2014 09:59 To: users@camel.apache.org Subject: RE: Somewhat inconsistent behaviour for message logging Hi Willem, I have mostly implemented this, however while writing a unit test I am wondering about the mixed case (both, the parameter and the context property are set). Let me state this in an example. For my test the formatted exchange looks like this: Exchange[ExchangePattern: InOnly, BodyType: String, Body: This is the message body] The maxChars parameter corresponds more or less to the length of this formatted exchange (including the body) (the actual length will be maxChars + 11). If I set the parameter to 55 I get Exchange[ExchangePattern: InOnly, BodyType: String, Body: This...] The Exchange.LOG_DEBUG_BODY_MAX_CHARS is actually for the message body. If I set the property to 7 I will get Exchange[ExchangePattern: InOnly, BodyType: String, Body: This is... [Body clipped after 7 chars, total length is 24]] So I wonder whether it would not be better to apply both settings if they are both set. What do you think? Best regards Stephan -----Original Message----- From: Willem Jiang [mailto:willem.ji...@gmail.com] Sent: Freitag, 28. November 2014 07:57 To: users@camel.apache.org Subject: RE: Somewhat inconsistent behaviour for message logging It is consistent behaviour to let DefaultExchangeFormatter take the consideration of Exchange.LOG_DEBUG_BODY_MAX_CHARS property. +1 for your proposer. -- 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 28, 2014 at 2:21:26 PM, Siano, Stephan (stephan.si...@sap.com) wrote: > 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:willem.ji...@gmail.com] > Sent: Freitag, 28. November 2014 06:28 > To: users@camel.apache.org > 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 (stephan.si...@sap.com) > 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 > > > >
