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 <[email protected]> > 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: [email protected] > For additional commands, e-mail: [email protected] > > > > > -- > E-Mail: [email protected] | [email protected] > 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
