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 <[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
>
