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 Mon, 23 Jul 2012 05:40:52 GMT
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 <ralph.goers@dslextreme.com>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 <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 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: 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