Great stuff. I'm working tomorrow and on vacation the rest of the week so I might have some more time to look at the code...
Gary On Mon, Jul 23, 2012 at 1:09 AM, Ralph Goers <[email protected]>wrote: > 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 > > > > > -- 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
