logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Understanding ParameterizedMessage and so on
Date Sun, 22 Jul 2012 20:57:32 GMT
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.

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.

(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.

(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).

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.

Gary


> >
> > 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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

Mime
View raw message