See below On Jul 22, 2012, at 1:57 PM, Gary Gregory wrote:
> 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"}. 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. > > At work, we are careful to pick good names, especially because we work with > developers in the EU, Russia and China. So communicating clearly is key. > > So with that hat on: > > (1) I would rename Message#getFormattedMessage to getMessageString. To me > getFormattedMessage, implies that there should be a getUnformattedMessage or > getMessage API. If a "formatted" message is the only choice I have, then keep > it simple with getMessageString. I put the String in getMessageString to > avoid confusion with the Message interface itself. getFormattedMessage does format the message in some way. With Parameterized message it performs parameter substitution. With Map message it formats the map, etc. The call to getMessageFormat returns whatever the "unformatted message". In the case of ParameterizedMessage that is the String still containing the "{}" specifiers. > > In addition, seeing an API called getFormattedMessage return a String when > there is an interface called FormattedMessage is confusing (to me.) because > the API does not return a FormattedMessage. I agree with this and is why I suggested renaming this interface to something else. > > (2) Rename org.apache.logging.log4j.message.Message.getMessageFormat() to > getFormat() because the "Message" in "getMessageFormat" is redundant > considering the API is on the Message interface. As above, I think about what > /other/ kind of Format I should be able to get, as in getFooFormat. If there > is one kind of format to get from a message, then getFormat says is all. This is apples and oranges. As I said, on a ParamertizedMessage this would return "Say hello to {}". It would not return "XML" or "JSON". > > (3) About the name for FromattedMessage vs Message. It is confusing that one > returns getFormat and the other getMessageFormat. Why not collapse the two > interfaces. Does the format need to be changed after instantiation? That > seems like an unlikely useful feature. I would guess that the format for a > message, for a whole logger really would be immutable (private final). Yes, it is confusing. I didn't want to add it to the Message interface because not every Message will accept additional formatting instructions. > > Thoughts? > > The @doubt tag in the Message interfaces feels like it is /too soon/ to call > for a VOTE without resolving all of these @doubt tags, 28 of them based on a > search of trunk of .java files. These should all be reflected in Jira. Curt never responded to any of my updates. I suspect it is primarily because he just doesn't have time. I should remove all the @doubt tags for issues that have been closed. Ralph
