[logback-user] Compiler selecting wrong Logger method

[Tony Trinh]

Actually, I meant the refactoring of a class that was being used by a "new
& improved" formatted string. If, for example, I had this formatted string:

log.debug("Loading Student [{0.number}] {0.name} Enrolled:
{0.enrollmentDate,date,yyyy-MM-dd}",student);

and down the road, someone decides to remove the number field from the Student
class without realizing it was in use here, the code would compile just
fine, but the effect (presumably an exception) would not be noticed until
this log statement was executed.


On Mon, Feb 13, 2012 at 12:35 PM, Chris Pratt <thechrispratt at gmail.com>wrote:

> Well, not exactly.  It works just fine with the Log4j/java.util.logging
> style logging, but it would require refactoring any SLF4j {} based
> mappings.  Then again, if it was added as an additional option rather than
> a replacement, that problem would go away as well.  If you could continue
> to get the Logger instances from the LoggerFactory, or a new Log instance
> that used my format, you could slowly transition to the "new & improved"
> without requiring a wholesale change.
>    (*Chris*)
>
> On Mon, Feb 13, 2012 at 9:24 AM, Tony Trinh <tony19 at gmail.com> wrote:
>
>> I'm a fan of this idea (if you couldn't already tell). A couple
>> disadvantages that come to mind is lack of syntax-checking in the string
>> and painful refactoring (it requires the programmer to search every
>> formatted string for correctness). In any case, what would be the
>> appropriate action for syntax errors that are discovered at runtime?
>>
>> -Tony
>>
>> On Mon, Feb 13, 2012 at 12:17 PM, Tony Trinh <tony19 at gmail.com> wrote:
>>
>>> +1 !!
>>>
>>>
>>> On Mon, Feb 13, 2012 at 11:47 AM, Chris Pratt <thechrispratt at gmail.com>wrote:
>>>
>>>> Sure, it uses an extension of the java.text.MessageFormat syntax that
>>>> allows for unlimited formatted varargs, and allows using dot-notation to
>>>> prevent evaluation of the methods until it's been deemed necessary.  With
>>>> the current libraries (all of them really), you have to evaluate all the
>>>> javabeans that hold the data you are looking to log before it's decided
>>>> whether to log the information or not.  In other words:
>>>>
>>>> log.debug("Loading Student [" + sdnt.getNumber() + "] " + sdnt.getName()
>>>> + " Enrolled: " + new SimpleDateFormat("yyyy-MM-dd").format(sdnt.
>>>> getEnrollmentDate()));
>>>>
>>>> Means that a lot of work is done and discarded when the debug level on
>>>> this file is set to info or less.  SLF4j is a little better, but not much:
>>>>
>>>> log.debug("Loading Student [{}] {} Enrolled: {}",new Object[] {sdnt.
>>>> getNumber(),sdnt.getName(),new SimpleDateFormat("yyyy-MM-dd").format
>>>> (sdnt.getEnrollmentDate())});
>>>>
>>>> Yes, of course you could (and probably should) wrap each and every call
>>>> to the log system in if(log.isDebugEnabled()) {}.  But we all know
>>>> that is ugly and easy for Jr programmers to forget.  My library puts off
>>>> the evaluation until after it's been decided that the information is
>>>> necessary, then efficiently outputs the message, like this:
>>>>
>>>> log.debug("Loading Student [{0.number}] {0.name} Enrolled:
>>>> {0.enrollmentDate,date,yyyy-MM-dd}",student);
>>>>
>>>> No muss, no fuss and the TextFormat utility is completely usable
>>>> standalone (as well as the advanced dot-notation utilities).
>>>>    (*Chris*)
>>>>
>>>>
>>
>> _______________________________________________
>> Logback-user mailing list
>> Logback-user at qos.ch
>> http://mailman.qos.ch/mailman/listinfo/logback-user
>>
>
>
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/logback-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20120213/1b237161/attachment-0001.html>