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"}. 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]
