RE: Somewhat inconsistent behaviour for message logging
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 1 > 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 > > 100
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 1 > 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 > > 1 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 >
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 1 > 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 > > 1 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 > > > >
RE: Somewhat inconsistent behaviour for message logging
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 1 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 1 > 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 >
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 1 > 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 >
