You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2012/07/22 22:32:12 UTC

MapMessage.asString() [WAS Re: Understanding ParameterizedMessage and so on]

Thread renamed to focus on
org.apache.logging.log4j.message.MapMessage.asString().

See below.

On Sun, Jul 22, 2012 at 3:09 PM, Ralph Goers <ra...@dslextreme.com>wrote:

>
> On Jul 22, 2012, at 5:50 AM, Gary Gregory wrote:
>
> > Hi All:
> >
> > Why does ParameterizedMessage class not implement the FormattedMessage
> interface? Are we making a conceptual difference between a formatted
> message and a parameterized message?
> >
> > The FM Javadoc says "A Message that can have a format String attached to
> it"; PM has a formattedMessage and messagePattern String. A messagePatterm
> sounds like a "format String" to me.
>
> Perhaps FormattedMessage is a bad name.  Every Message implements
> getFormattedMessage().  The purpose of the FromattedMessage interface is to
> signify that a Message can accept additional information to help it to
> determine how to format the message. In the specific cases it is used in
> currently, MapMessage normally defaults to formatting the Map as
> {key1="value1" key2="value2"}.


Wow, this is so close to being JSON, why not make is JSON?

For example:

{"key1": "value1", "key2": "value2"}

Since the Map is <String, String>, we do not have to worry about nested
structures or arrays.

Or, at least create an enum with XML and JSON and a third option which is
what you have now (call it SIMPLE).

Note that as it is now, IMO, it is odd to have the separator be " " instead
of ", ".

Gary


> If setFormat() is called with a value of "XML" then the Map is rendered as
> XML instead.  So really what is being done is providing so extra formatting
> instructions. If you can think of a less confusing name than Formatted
> Message I'd readily agree.
>
> >
> > Would it not be simpler to have
> org.apache.logging.log4j.message.Message.getFormattedMessage() as
> toString()? Is a toString() on each Message impl that useful for debugging
> that it overrides the simplicity of using toString?
>
> I know Joern and I had discussions around this a long time ago (he
> actually wrote ParameterizedMessage before I even started on Log4j 2) but I
> can't recall the reasons why we decided that using getFormattedMessage was
> better.
>
>
> >
> > ThreadDumpMessage does not implement toString(). Is that on purpose or
> an omission?
>
> IMO, technically every object should override toString() as what Java
> prints isn't always useful. But it isn't required since Java provides a
> default implementation and it isn't required by the MessageInterface.  Now
> that I think about it, this is probably exactly why Message requires
> getFormattedMessage().
>
> Ralph
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: MapMessage.asString() [WAS Re: Understanding ParameterizedMessage and so on]

Posted by Ralph Goers <ra...@dslextreme.com>.

On Jul 22, 2012, at 1:59 PM, Gary Gregory wrote:

> If you keep the current format, I would have an enum like {XML, JSON, JAVA_MAP} (or MAP)

I've thought of that.  However, the usage of this is that in the PatternLayout you can specify %msg{XML} or %msg{JSON}.  If the message is an instance of a FormattedMessage than setFormat is called and passed the String.   Again, the idea is to allow the person configuring Log4j to provide some "advice" to the Messages as to how to do formatting. For example, %msg{JSON} would basically say "any Message that supports JSON should use that format".  Having to update an enum would limit what end users could do.

I'm sure there are some issues with this as MapMessage (and any FormattedMessage) actually needs to accept a list of tokens and ignore those it doesn't understand. 

Again, if you have another idea of how to achieve this let me know.  As a matter of fact, I can already see a problem with this as it isn't really safe. The message might be passed to two different appenders with different layouts. The configuration of one Appender's layout will affect the other.  

I need to rethink how this is done.

Ralph

> 
> Gary
> 
> On Sun, Jul 22, 2012 at 4:57 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> Darn, another bug.
> 
> The default formatting is supposed to use the same format as Map.toString((). However, toString() separates the key/value pairs with ", " not just a space.  I will fix that. And adding JSON as a format seems reasonable too.
> 
> Ralph
> 
> On Jul 22, 2012, at 1:32 PM, Gary Gregory wrote:
> 
>> Thread renamed to focus on org.apache.logging.log4j.message.MapMessage.asString().
>> 
>> See below.
>> 
>> On Sun, Jul 22, 2012 at 3:09 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>> 
>> On Jul 22, 2012, at 5:50 AM, Gary Gregory wrote:
>> 
>> > Hi All:
>> >
>> > Why does ParameterizedMessage class not implement the FormattedMessage interface? Are we making a conceptual difference between a formatted message and a parameterized message?
>> >
>> > The FM Javadoc says "A Message that can have a format String attached to it"; PM has a formattedMessage and messagePattern String. A messagePatterm sounds like a "format String" to me.
>> 
>> Perhaps FormattedMessage is a bad name.  Every Message implements getFormattedMessage().  The purpose of the FromattedMessage interface is to signify that a Message can accept additional information to help it to determine how to format the message. In the specific cases it is used in currently, MapMessage normally defaults to formatting the Map as {key1="value1" key2="value2"}.
>> 
>> Wow, this is so close to being JSON, why not make is JSON? 
>> 
>> For example:
>> 
>> {"key1": "value1", "key2": "value2"}
>> 
>> Since the Map is <String, String>, we do not have to worry about nested structures or arrays.
>> 
>> Or, at least create an enum with XML and JSON and a third option which is what you have now (call it SIMPLE).
>> 
>> Note that as it is now, IMO, it is odd to have the separator be " " instead of ", ".
>> 
>> Gary
>>  
>> If setFormat() is called with a value of "XML" then the Map is rendered as XML instead.  So really what is being done is providing so extra formatting instructions. If you can think of a less confusing name than Formatted Message I'd readily agree.
>> 
>> >
>> > Would it not be simpler to have org.apache.logging.log4j.message.Message.getFormattedMessage() as toString()? Is a toString() on each Message impl that useful for debugging that it overrides the simplicity of using toString?
>> 
>> I know Joern and I had discussions around this a long time ago (he actually wrote ParameterizedMessage before I even started on Log4j 2) but I can't recall the reasons why we decided that using getFormattedMessage was better.
>> 
>> 
>> >
>> > ThreadDumpMessage does not implement toString(). Is that on purpose or an omission?
>> 
>> IMO, technically every object should override toString() as what Java prints isn't always useful. But it isn't required since Java provides a default implementation and it isn't required by the MessageInterface.  Now that I think about it, this is probably exactly why Message requires getFormattedMessage().
>> 
>> Ralph
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> 
>> 
>> 
>> 
>> -- 
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com 
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
> 
> 
> 
> 
> -- 
> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory


Re: MapMessage.asString() [WAS Re: Understanding ParameterizedMessage and so on]

Posted by Gary Gregory <ga...@gmail.com>.
If you keep the current format, I would have an enum like {XML, JSON,
JAVA_MAP} (or MAP)

Gary

On Sun, Jul 22, 2012 at 4:57 PM, Ralph Goers <ra...@dslextreme.com>wrote:

> Darn, another bug.
>
> The default formatting is supposed to use the same format as
> Map.toString((). However, toString() separates the key/value pairs with ",
> " not just a space.  I will fix that. And adding JSON as a format seems
> reasonable too.
>
> Ralph
>
> On Jul 22, 2012, at 1:32 PM, Gary Gregory wrote:
>
> Thread renamed to focus on
> org.apache.logging.log4j.message.MapMessage.asString().
>
> See below.
>
> On Sun, Jul 22, 2012 at 3:09 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>>
>> On Jul 22, 2012, at 5:50 AM, Gary Gregory wrote:
>>
>> > Hi All:
>> >
>> > Why does ParameterizedMessage class not implement the FormattedMessage
>> interface? Are we making a conceptual difference between a formatted
>> message and a parameterized message?
>> >
>> > The FM Javadoc says "A Message that can have a format String attached
>> to it"; PM has a formattedMessage and messagePattern String. A
>> messagePatterm sounds like a "format String" to me.
>>
>> Perhaps FormattedMessage is a bad name.  Every Message implements
>> getFormattedMessage().  The purpose of the FromattedMessage interface is to
>> signify that a Message can accept additional information to help it to
>> determine how to format the message. In the specific cases it is used in
>> currently, MapMessage normally defaults to formatting the Map as
>> {key1="value1" key2="value2"}.
>
>
> Wow, this is so close to being JSON, why not make is JSON?
>
> For example:
>
> {"key1": "value1", "key2": "value2"}
>
> Since the Map is <String, String>, we do not have to worry about nested
> structures or arrays.
>
> Or, at least create an enum with XML and JSON and a third option which is
> what you have now (call it SIMPLE).
>
> Note that as it is now, IMO, it is odd to have the separator be " "
> instead of ", ".
>
> Gary
>
>
>> If setFormat() is called with a value of "XML" then the Map is rendered
>> as XML instead.  So really what is being done is providing so extra
>> formatting instructions. If you can think of a less confusing name than
>> Formatted Message I'd readily agree.
>>
>> >
>> > Would it not be simpler to have
>> org.apache.logging.log4j.message.Message.getFormattedMessage() as
>> toString()? Is a toString() on each Message impl that useful for debugging
>> that it overrides the simplicity of using toString?
>>
>> I know Joern and I had discussions around this a long time ago (he
>> actually wrote ParameterizedMessage before I even started on Log4j 2) but I
>> can't recall the reasons why we decided that using getFormattedMessage was
>> better.
>>
>>
>> >
>> > ThreadDumpMessage does not implement toString(). Is that on purpose or
>> an omission?
>>
>> IMO, technically every object should override toString() as what Java
>> prints isn't always useful. But it isn't required since Java provides a
>> default implementation and it isn't required by the MessageInterface.  Now
>> that I think about it, this is probably exactly why Message requires
>> getFormattedMessage().
>>
>> Ralph
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: MapMessage.asString() [WAS Re: Understanding ParameterizedMessage and so on]

Posted by Ralph Goers <ra...@dslextreme.com>.
Actually, looking at this again the default also isn't enclosed in '{' and '}'.  I'm sure I have a reason why but I need to dig a bit.

Ralph

On Jul 22, 2012, at 1:57 PM, Ralph Goers wrote:

> Darn, another bug.
> 
> The default formatting is supposed to use the same format as Map.toString((). However, toString() separates the key/value pairs with ", " not just a space.  I will fix that. And adding JSON as a format seems reasonable too.
> 
> Ralph
> 
> On Jul 22, 2012, at 1:32 PM, Gary Gregory wrote:
> 
>> Thread renamed to focus on org.apache.logging.log4j.message.MapMessage.asString().
>> 
>> See below.
>> 
>> On Sun, Jul 22, 2012 at 3:09 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>> 
>> On Jul 22, 2012, at 5:50 AM, Gary Gregory wrote:
>> 
>> > Hi All:
>> >
>> > Why does ParameterizedMessage class not implement the FormattedMessage interface? Are we making a conceptual difference between a formatted message and a parameterized message?
>> >
>> > The FM Javadoc says "A Message that can have a format String attached to it"; PM has a formattedMessage and messagePattern String. A messagePatterm sounds like a "format String" to me.
>> 
>> Perhaps FormattedMessage is a bad name.  Every Message implements getFormattedMessage().  The purpose of the FromattedMessage interface is to signify that a Message can accept additional information to help it to determine how to format the message. In the specific cases it is used in currently, MapMessage normally defaults to formatting the Map as {key1="value1" key2="value2"}.
>> 
>> Wow, this is so close to being JSON, why not make is JSON? 
>> 
>> For example:
>> 
>> {"key1": "value1", "key2": "value2"}
>> 
>> Since the Map is <String, String>, we do not have to worry about nested structures or arrays.
>> 
>> Or, at least create an enum with XML and JSON and a third option which is what you have now (call it SIMPLE).
>> 
>> Note that as it is now, IMO, it is odd to have the separator be " " instead of ", ".
>> 
>> Gary
>>  
>> If setFormat() is called with a value of "XML" then the Map is rendered as XML instead.  So really what is being done is providing so extra formatting instructions. If you can think of a less confusing name than Formatted Message I'd readily agree.
>> 
>> >
>> > Would it not be simpler to have org.apache.logging.log4j.message.Message.getFormattedMessage() as toString()? Is a toString() on each Message impl that useful for debugging that it overrides the simplicity of using toString?
>> 
>> I know Joern and I had discussions around this a long time ago (he actually wrote ParameterizedMessage before I even started on Log4j 2) but I can't recall the reasons why we decided that using getFormattedMessage was better.
>> 
>> 
>> >
>> > ThreadDumpMessage does not implement toString(). Is that on purpose or an omission?
>> 
>> IMO, technically every object should override toString() as what Java prints isn't always useful. But it isn't required since Java provides a default implementation and it isn't required by the MessageInterface.  Now that I think about it, this is probably exactly why Message requires getFormattedMessage().
>> 
>> Ralph
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> 
>> 
>> 
>> 
>> -- 
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com 
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
> 


Re: MapMessage.asString() [WAS Re: Understanding ParameterizedMessage and so on]

Posted by Ralph Goers <ra...@dslextreme.com>.
Darn, another bug.

The default formatting is supposed to use the same format as Map.toString((). However, toString() separates the key/value pairs with ", " not just a space.  I will fix that. And adding JSON as a format seems reasonable too.

Ralph

On Jul 22, 2012, at 1:32 PM, Gary Gregory wrote:

> Thread renamed to focus on org.apache.logging.log4j.message.MapMessage.asString().
> 
> See below.
> 
> On Sun, Jul 22, 2012 at 3:09 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> 
> On Jul 22, 2012, at 5:50 AM, Gary Gregory wrote:
> 
> > Hi All:
> >
> > Why does ParameterizedMessage class not implement the FormattedMessage interface? Are we making a conceptual difference between a formatted message and a parameterized message?
> >
> > The FM Javadoc says "A Message that can have a format String attached to it"; PM has a formattedMessage and messagePattern String. A messagePatterm sounds like a "format String" to me.
> 
> Perhaps FormattedMessage is a bad name.  Every Message implements getFormattedMessage().  The purpose of the FromattedMessage interface is to signify that a Message can accept additional information to help it to determine how to format the message. In the specific cases it is used in currently, MapMessage normally defaults to formatting the Map as {key1="value1" key2="value2"}.
> 
> Wow, this is so close to being JSON, why not make is JSON? 
> 
> For example:
> 
> {"key1": "value1", "key2": "value2"}
> 
> Since the Map is <String, String>, we do not have to worry about nested structures or arrays.
> 
> Or, at least create an enum with XML and JSON and a third option which is what you have now (call it SIMPLE).
> 
> Note that as it is now, IMO, it is odd to have the separator be " " instead of ", ".
> 
> Gary
>  
> If setFormat() is called with a value of "XML" then the Map is rendered as XML instead.  So really what is being done is providing so extra formatting instructions. If you can think of a less confusing name than Formatted Message I'd readily agree.
> 
> >
> > Would it not be simpler to have org.apache.logging.log4j.message.Message.getFormattedMessage() as toString()? Is a toString() on each Message impl that useful for debugging that it overrides the simplicity of using toString?
> 
> I know Joern and I had discussions around this a long time ago (he actually wrote ParameterizedMessage before I even started on Log4j 2) but I can't recall the reasons why we decided that using getFormattedMessage was better.
> 
> 
> >
> > ThreadDumpMessage does not implement toString(). Is that on purpose or an omission?
> 
> IMO, technically every object should override toString() as what Java prints isn't always useful. But it isn't required since Java provides a default implementation and it isn't required by the MessageInterface.  Now that I think about it, this is probably exactly why Message requires getFormattedMessage().
> 
> Ralph
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 
> 
> 
> 
> -- 
> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory