[logback-user] Custom formatting of parameterized string

[Ralph Goers]

Ceki usually is pretty responsive but I haven't seen him post for a  
few days. I'm guessing he must be taking a few days off.

On Sep 9, 2009, at 7:04 PM, david_z wrote:

>
> Hi,
> I'm new to logback and am in the process of evaluating as a  
> replacement for
> log4j.  A question was raised today at work regarding parameterized  
> logging
> and the ability to modify logback to support java.text.MessageFormat  
> style
> formatting in order to, for example, perform date or currency  
> formatting:
> log.debug("myDate={0,date,MMM d}", myDate);
> log.debug("myAmount={0,number,currency}", myAmount);
>
> or to defer array formatting, similar to the question I'm replying  
> to above.
>
> I appreciate the performance reasons for logback using {}  
> replacement, but
> it seems like it should be possible to allow the user to provide an
> alternate formatting strategy if they so desire without negatively  
> impacting
> the default's performance.  Creating my own MessageConverter, as  
> suggested
> above, to perform this formatting works fine, except the conversion is
> performed once per appender per event rather than just once per event.
>
> Is there a better way to handle this custom formatting goal?

Actually, the MessageConverter doesn't do anything. All it does is  
retrieve the message as it was formatted by SLF4J. If you want to do  
formatting then create your own layout and/or converter.
>
> If not, I have a suggestion for an enhancement.
> 1. Add a Formatter interface with the method
>   String format(String messagePattern, Object[] argArray)

Converters implement String convert(ILoggingEvent event).  If you look  
at how the pattern layout works, the parameters for the individual  
converters are passed to them.

> 2. The LoggingEvent would need access to the formatter.  Ideally the
> Formatter could be configured via the config file as the Converters  
> can be.
> I don't know enough about the source to flesh this part out well.

It works the other way around. The Converters have access to the  
logging event.

> 3. Modify getFormattedMessage() in the ILoggingEvent implementations
>  public String getFormattedMessage() {
>    if (formattedMessage != null) {
>      return formattedMessage;
>    }
>    if (argumentArray != null) {
>      if (formatter == null) {
>        formattedMessage = MessageFormatter.arrayFormat(message,
> argumentArray);
>      } else {
>        formattedMessage = formatter.format(message, argumentArray);
>      }
>    } else {
>      formattedMessage = message;
>    }
>    return formattedMessage;
>  }
> What do you think?
>

1. I think Logback already provides a mechanism to do what you want.
2. I've been working on an enhancement to SLF4J and  logback to  
support RFC 5424, the new IETF syslog specification. (See  http://tools.ietf.org/html/rfc5424 
). In particular, the concept of Structured Data. You can play with  
what I have so far by checking it out from git://github.com/rgoers/slf4j.git 
  and git://github.com/rgoers/logback.git. However, your idea of  
associating a converter with specific keys isn't something I had  
thought of but is worth considering, however I'd probably want to  
provide the definitions in the configuration, not in the actual logger  
calls. So far I've just focused on implementing something that adheres  
to the specification but I'd be interested in suggestions on how to  
improve it.


Ralph

Ralph