[slf4j-user] Replaceable MessageFormatter

[Chris Pratt]

Joachim,

  I'm not sure what you are saying is "happening so rarely" for you??  Are
you saying you log information so infrequently that you rarely either do
log.debug("The file " + file.getAbsoluteFile().toString() + " was created
on " + file.lastModified()) or do log.debug("The file {} was created on
{}",file.getAbsoluteFile().toString(),file.lastModified());?  In both
cases, you are performing computations that are thrown away in a production
environment.

Ceki had a valid point that replaceable loggers would be a bad idea, so I'm
no longer proposing that.  My proposal would be for a single, more
powerful, formatter that could handle something like log.debug("The file
{0.absoluteFile} was created on {0.lastModified,date,yyyy-MM-dd",file);
  (*Chris*)


On Thu, Dec 26, 2013 at 2:11 PM, Joachim Durchholz <jo at durchholz.org> wrote:

> Am 26.12.2013 20:46, schrieb Chris Pratt:
>
>  You recognized that
>> constructing a string to be thrown away when it was determined the logging
>> level was insufficient was inefficient, which is totally true, but it
>> fails
>> to take into consideration that just accessing and formatting the data for
>> display can be quite costly as well.  I would propose to extend the
>> already
>> existing replacement parameters, giving them the ability to be
>> positionally
>> referenced, dot notated, and format specified to prevent retrieving and
>> formatting data before it's known that the data is necessary.
>>
>
> FWIW, this has been happening so rarely for me that I do not consider the
> occasional if(logger.isDebugEnabled()) block burdensome.
>
> There's also the question of how much does one want in the format: The
> maximal solution would be an interpreter for something Turing-complete in
> the format, which is obviously way over the top, the minimal solution would
> be what we're having now: just substitute in expressions. Some decision
> should be made at what point between these extremes SLF4J should lie,
> otherwise, adding a formatter here and extending it there will end with
> evil feature creep. (If there are too many formatters of that kind around,
> there's also the burden of deciding which formatter to use, making SLF4J
> more complicated to use; it's not a long-term concern, but it would raise
> the entry barrier.)
>
> Finally, I think Java 8's closures will make the entire point moot. Make
> the SLF4J logging functions accept a String-returning closure, and specify
> whatever computations you want inside the parameter - it won't be evaluated
> until SLF4J actually runs it.
> Of course, not everybody can postpone such issues to Java 8.
>
> Just my 2 cents on that topic.
> Back to lurking mode :-)
>
> _______________________________________________
> slf4j-user mailing list
> slf4j-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20131226/addf486a/attachment-0001.html>