logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Understanding ParameterizedMessage and so on
Date Sun, 22 Jul 2012 21:13:17 GMT
See below

On Jul 22, 2012, at 1:57 PM, Gary Gregory wrote:

> On Sun, Jul 22, 2012 at 3:09 PM, Ralph Goers <ralph.goers@dslextreme.com> 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

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

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

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.


View raw message