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 <[email protected]>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 > <[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://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: [email protected] | [email protected] 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
