On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pbened...@apache.org> wrote:
> Ralph,
>
> This is actually a discussion you and I had a while back when I was trying
> to figure out how to use String.format(). I like the model now of
> specifying the message class... however...
>
> It does seem a bit unseemly to instantiate an xxxMessage object that may
> never get used. I'd rather just pass in the Class<?> and let the logger
> instantiate it only if it is going to log something. The only downside is
> then configuring the actual class.
>
Yes, that's a lot of garbage to generate if a given level is not enabled,
unless you guard with is{Level}Enabled(), which I do.
If my logger.debug() call is not creating objects, then I do not need to
guard it. I wonder if it is better to consistently guard, kind of like
always like using {} blocks for if/while/for/do that are one-liners.
My app is not fast by nature, so logging performance is not an issue for
now, and I'd rather have the more expressive formatting for debugging.
Generating garbage would be an issue though as my app is memory intensive.
Gary
> Thoughts?
>
> Paul
>
>
> On Thu, Oct 4, 2012 at 4:51 PM, Ralph Goers <ralph.go...@dslextreme.com>wrote:
>
>> Yeah - the downside of that wrapper is that it is going to record the
>> file, method and line as that of the error method, not of the caller of the
>> error method. That is actually why so many methods are already in
>> AbstractLogger (and the Logger interface). I have no problem with adding
>> more if they make sense. IMO, the goal of the interface is to make
>> invoking logging simpler.
>>
>> However, I don't really care for "formatError" as a name.
>>
>> I am assuming that what you are really looking for is a set of methods
>> that use a StringFormattedMessage instead of a ParameterizedMessage. I'm
>> OK with that but I would want it made clear in the API documentation that
>> they are 5-10 times slower in performing substitution than the existing
>> methods.
>>
>> Ralph
>>
>> On Oct 4, 2012, at 2:34 PM, Gary Gregory wrote:
>>
>> On Thu, Oct 4, 2012 at 5:10 PM, Ralph Goers
>> <ralph.go...@dslextreme.com>wrote:
>>
>>> One other thing. I would recommend changing your code below to
>>>
>>> public void error(final Throwable t, final String format, final
>>> Object... values) {
>>> this.logger.error(new StringFormattedMessage(format, values), t);
>>> }
>>>
>>
>> Cool! OK, now I have:
>>
>> public void error(final String format, final Throwable t, final
>> Object... values) {
>> this.logger.debug(new StringFormattedMessage(format, values), t);
>> }
>>
>>
>> But what about simply providing an API for this pattern? Like:
>>
>> this.logger.formatError(format, t, values);
>>
>> I'm not sure if "formatError" is the best name, but you get the idea.
>>
>> This would let me get ride of a bunch of boiler plate code!
>>
>> G
>>
>>
>>
>>
>>>
>>> This way String.format() isn't called unless the event is going to be
>>> logged.
>>>
>>> I'm not sure why your error method is logging at debug.
>>>
>>> Ralph
>>>
>>>
>>> On Oct 4, 2012, at 11:29 AM, Gary Gregory wrote:
>>>
>>> Hi All:
>>>
>>> In 2.0-Beta1, I have:
>>>
>>> public void error(final Throwable t, final String format, final
>>> Object... values) {
>>> this.logger.debug(String.format(format, values), t);
>>> }
>>>
>>> The formatted string is logged to the console but not the Exception.
>>>
>>> Am I missing something?
>>>
>>> My config looks like this:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <configuration status="OFF">
>>> <appenders>
>>> <Console name="Console" target="SYSTEM_OUT">
>>> <PatternLayout pattern="%d{ ISO8601 } [%t] %-5level: %msg%n" />
>>> </Console>
>>> </appenders>
>>> <loggers>
>>> <logger name="com.foo" level="DEBUG" />
>>> <logger name="com.foo.bar" level="INFO" />
>>> <logger name="com.gargoylesoftware" level="INFO" />
>>> <root level="INFO">
>>> <appender-ref ref="Console" />
>>> </root>
>>> </loggers>
>>> </configuration>
>>>
>>> Merci!
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@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
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@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
>>
>>
>>
>
--
E-Mail: garydgreg...@gmail.com | ggreg...@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
