You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "Siano, Stephan" <st...@sap.com> on 2014/11/27 14:34:57 UTC
Somewhat inconsistent behaviour for message logging
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
RE: Somewhat inconsistent behaviour for message logging
Posted by "Siano, Stephan" <st...@sap.com>.
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.siano@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.jiang@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.siano@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.jiang@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.siano@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
> >
>
>
RE: Somewhat inconsistent behaviour for message logging
Posted by "Siano, Stephan" <st...@sap.com>.
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.jiang@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.siano@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.jiang@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.siano@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
> >
>
>
RE: Somewhat inconsistent behaviour for message logging
Posted by Willem Jiang <wi...@gmail.com>.
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.siano@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.jiang@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.siano@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
> >
>
>
RE: Somewhat inconsistent behaviour for message logging
Posted by "Siano, Stephan" <st...@sap.com>.
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.jiang@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.siano@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
>
Re: Somewhat inconsistent behaviour for message logging
Posted by Willem Jiang <wi...@gmail.com>.
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.siano@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
>