[logback-user] Compiler selecting wrong Logger method

[Chris Pratt]

That's a good point, right now it would eat the exception (logging should
never interfere with the operation of a possibly production system) and
just log a "null" for that value, which isn't as helpful as it could be.
 Maybe I could have it log "missing value:0.number" or something like that.
  (*Chris*)

On Mon, Feb 13, 2012 at 9:44 AM, Tony Trinh <tony19 at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/ddfe0d1b/attachment.html>