I removed the @doubt tags for Jira issues that are closed. Others could probably be removed but I'm leaving them to see if anyone else has comments on them.
I renamed FormattedMessage to MultiformatMessage and got rid of the setter and getter. Instead it also declares String getFormattedMessage(String[] formats); This is called from the MessagePatternConverter if the Message implements MultiformatMessage, otherwise getFormattedMsg() is called. Ralph On Jul 22, 2012, at 2:13 PM, Ralph Goers wrote: > 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 > > >
