You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2012/10/04 20:29:51 UTC
Exception not logged?
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: garydgregory@gmail.com | ggregory@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
Re: Exception not logged?
Posted by Ralph Goers <ra...@dslextreme.com>.
I think that is a great idea. Do you want to take a stab at implementing it in AbstractLogger?
Ralph
On Oct 4, 2012, at 2:55 PM, Paul Benedict 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.
>
> Thoughts?
>
> Paul
>
> On Thu, Oct 4, 2012 at 4:51 PM, Ralph Goers <ra...@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 <ra...@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: garydgregory@gmail.com | ggregory@apache.org
>>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>>> Spring Batch in Action: http://bit.ly/bqpbCK
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
Re: Exception not logged?
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Oct 5, 2012 at 2:03 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> I updated ReflectionComparison to include comparing creating the object
> via "new" and via reflection.
>
> Timer NewObject stopped. Elapsed time: 0.019149000 seconds Average per
> iteration: 0.000000019 seconds
> Timer ReflectionObject stopped. Elapsed time: 0.171598000 seconds Average
> per iteration: 0.000000171 seconds
>
> So reflection definitely is noticeably slower, but this is only going to
> occur after filtering has passed and is probably a good tradeoff for
> avoiding calling "new" in the application until it is actually needed. For
> example, there would probably be hundreds of logging calls that wouldn't
> create an object because filtering didn't pass, thus compensating for the
> extra cost of allocating the objects and immediately discarding them.
> OTOH, doing
>
> if (logger.isDebugEnabled()) {
> logger.debug(new StringFormattedMessage(format, param));
> }
>
I wonder if you could simplify the class names...
StringFormattedMessage to one of:
- StringMessage
- FormattedMessage
- StringFormatMessage
ParameterizedMessage could be:
- TokenMessage
- BracketMessage
- SimpleMessage
All of the xxx'ed names seem a little odd to me, not to say wordy.
?
> would probably perform better than
>
> logger.debug(StringFormattedMessage.class, format, param);
>
> Ralph
>
>
> On Oct 5, 2012, at 8:35 AM, Gary Gregory wrote:
>
> On Thu, Oct 4, 2012 at 10:54 PM, Ralph Goers <rg...@apache.org> wrote:
>
>> Yup. That is what I would expect. However, it probably requires a
>> Message that has a constructor that accepts a Throwable and an object
>> array, which means we would probably want a new interface as a marker.
>>
>
> So would reflection be used at runtime to instantiate the message?
> Wouldn't that be a performance hit?
>
> We could just provide APIs in AbstractLogger for the built-in message
> classes that do the instance creation w/o reflection.
>
> Thoughts?
>
> Gary
>
>
>> Ralph
>>
>> Sent from my iPad
>>
>> On Oct 4, 2012, at 7:18 PM, Paul Benedict <pb...@apache.org> wrote:
>>
>> Ooops. I meant this:
>>
>> logger.debug(Class<? extends Message> m, Throwable t, Object...
>> messageParams);
>>
>> The point was to pass in the Class of the Message so it doesn't get
>> instantiated unless logging is going to occur.
>>
>> Paul
>>
>> On Thu, Oct 4, 2012 at 9:12 PM, Gary Gregory <ga...@gmail.com>wrote:
>>
>>> On Thu, Oct 4, 2012 at 10:06 PM, Paul Benedict <pb...@apache.org>wrote:
>>>
>>>> On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory <ga...@gmail.com>wrote:
>>>>
>>>>> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pb...@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.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>
>>>>> So instead of:
>>>>>
>>>>> this.logger.debug(new StringFormattedMessage(format, values), t);
>>>>>
>>>>> I would do:
>>>>>
>>>>> this.logger.debug(StringFormattedMessage.class, t, format, values);
>>>>>
>>>>>
>>>> I was thinking of adding this signature:
>>>> logger.debug(Message m, Throwable t, Object... messageParams);
>>>>
>>>> Thoughts?
>>>>
>>>
>>> Pardon me for being dense, but how does that help in the case of my
>>> examples?
>>>
>>> Thank you in advance for clarifying,
>>> Gary
>>>
>>>>
>>>> Paul
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: Exception not logged?
Posted by Tushar Kapila <tg...@gmail.com>.
This looks like a real mem saver
static {
logger.registerMessage("messagekey", new StringFormattedMessage("%s"));
}
public void run(String param) {
logger.debug("messagekey", param);
Ofcourse doc should say what is thread safe and how to use. Unrelated
but same idea: We saved a few milliseconds and few 1,000 objects by
caching SimpleDateFormats - but can only used the shared instances for
format and not parse
On 10/6/2012 12:23 AM, Paul Benedict wrote:
> After reading this email, it occurred to me that Messages/Formats are
> typically static. Once instantiated, there is really no need to
> instantiate it over and over.
>
> Rather than specifying the Class<?>, perhaps there should be a
> registration feature. Maybe like this:
>
> public class MyApp {
> public static Logger logger;
> static {
> logger.registerMessage("messagekey", new
> StringFormattedMessage("%s"));
> }
>
> public void run(String param) {
> logger.debug("messagekey", param);
> }
> }
>
> Paul
>
> On Fri, Oct 5, 2012 at 1:03 PM, Ralph Goers
> <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>
> I updated ReflectionComparison to include comparing creating the
> object via "new" and via reflection.
>
> Timer NewObject stopped. Elapsed time: 0.019149000 seconds Average
> per iteration: 0.000000019 seconds
> Timer ReflectionObject stopped. Elapsed time: 0.171598000 seconds
> Average per iteration: 0.000000171 seconds
>
> So reflection definitely is noticeably slower, but this is only
> going to occur after filtering has passed and is probably a good
> tradeoff for avoiding calling "new" in the application until it is
> actually needed. For example, there would probably be hundreds of
> logging calls that wouldn't create an object because filtering
> didn't pass, thus compensating for the extra cost of allocating
> the objects and immediately discarding them. OTOH, doing
>
> if (logger.isDebugEnabled()) {
> logger.debug(new StringFormattedMessage(format, param));
> }
>
> would probably perform better than
>
> logger.debug(StringFormattedMessage.class, format, param);
>
> Ralph
>
>
> On Oct 5, 2012, at 8:35 AM, Gary Gregory wrote:
>
>> On Thu, Oct 4, 2012 at 10:54 PM, Ralph Goers <rgoers@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Yup. That is what I would expect. However, it probably
>> requires a Message that has a constructor that accepts a
>> Throwable and an object array, which means we would probably
>> want a new interface as a marker.
>>
>>
>> So would reflection be used at runtime to instantiate the
>> message? Wouldn't that be a performance hit?
>>
>> We could just provide APIs in AbstractLogger for the built-in
>> message classes that do the instance creation w/o reflection.
>>
>> Thoughts?
>>
>> Gary
>>
>>
>> Ralph
>>
>> Sent from my iPad
>>
>> On Oct 4, 2012, at 7:18 PM, Paul Benedict
>> <pbenedict@apache.org <ma...@apache.org>> wrote:
>>
>>> Ooops. I meant this:
>>>
>>> logger.debug(Class<? extends Message> m, Throwable t,
>>> Object... messageParams);
>>>
>>> The point was to pass in the Class of the Message so it
>>> doesn't get instantiated unless logging is going to occur.
>>>
>>> Paul
>>>
>>> On Thu, Oct 4, 2012 at 9:12 PM, Gary Gregory
>>> <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> On Thu, Oct 4, 2012 at 10:06 PM, Paul Benedict
>>> <pbenedict@apache.org <ma...@apache.org>> wrote:
>>>
>>> On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory
>>> <garydgregory@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict
>>> <pbenedict@apache.org
>>> <ma...@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.
>>>
>>> Thoughts?
>>>
>>>
>>> So instead of:
>>>
>>> this.logger.debug(new
>>> StringFormattedMessage(format, values), t);
>>>
>>> I would do:
>>>
>>> this.logger.debug(StringFormattedMessage.class,
>>> t, format, values);
>>>
>>>
>>> I was thinking of adding this signature:
>>> logger.debug(Message m, Throwable t, Object...
>>> messageParams);
>>>
>>> Thoughts?
>>>
>>>
>>> Pardon me for being dense, but how does that help in the
>>> case of my examples?
>>>
>>> Thank you in advance for clarifying,
>>> Gary
>>>
>>>
>>> Paul
>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com
>>> <ma...@gmail.com> | ggregory@apache.org
>>> <ma...@apache.org>
>>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>>> Spring Batch in Action: http://bit.ly/bqpbCK
>>> Blog: http://garygregory.wordpress.com
>>> <http://garygregory.wordpress.com/>
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> |
>> ggregory@apache.org <ma...@apache.org>
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> <http://garygregory.wordpress.com/>
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
Re: Exception not logged?
Posted by Gary Gregory <ga...@gmail.com>.
Well, let's start that one in a separate thread. ;) G.
On Fri, Oct 5, 2012 at 4:11 PM, Paul Benedict <pb...@apache.org> wrote:
> IMO, I thought all Message implements should be stateless. Maybe that
> should be part of the Message interface contract anyway, regardless of my
> idea.
>
> Paul
>
>
> On Fri, Oct 5, 2012 at 3:06 PM, Gary Gregory <ga...@gmail.com>wrote:
>
>> That's clever but... when happens when multiple threads call run(String)?
>> We'd need to make sure all Message implementations are stateless.
>>
>> I'm not sure I'd want to keep both places in the code in sync too. Every
>> time I want to fiddle with a message format, I have to make sure both spots
>> match. Seems to painful to me. An interesting thought though, but it does
>> not make my life easier as a v2 user...
>>
>> Gary
>>
>> On Fri, Oct 5, 2012 at 2:53 PM, Paul Benedict <pb...@apache.org>wrote:
>>
>>> After reading this email, it occurred to me that Messages/Formats are
>>> typically static. Once instantiated, there is really no need to instantiate
>>> it over and over.
>>>
>>> Rather than specifying the Class<?>, perhaps there should be a
>>> registration feature. Maybe like this:
>>>
>>> public class MyApp {
>>> public static Logger logger;
>>> static {
>>> logger.registerMessage("messagekey", new
>>> StringFormattedMessage("%s"));
>>> }
>>>
>>> public void run(String param) {
>>> logger.debug("messagekey", param);
>>> }
>>> }
>>>
>>> Paul
>>>
>>>
>>> On Fri, Oct 5, 2012 at 1:03 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>>>
>>>> I updated ReflectionComparison to include comparing creating the object
>>>> via "new" and via reflection.
>>>>
>>>> Timer NewObject stopped. Elapsed time: 0.019149000 seconds Average per
>>>> iteration: 0.000000019 seconds
>>>> Timer ReflectionObject stopped. Elapsed time: 0.171598000 seconds
>>>> Average per iteration: 0.000000171 seconds
>>>>
>>>> So reflection definitely is noticeably slower, but this is only going
>>>> to occur after filtering has passed and is probably a good tradeoff for
>>>> avoiding calling "new" in the application until it is actually needed. For
>>>> example, there would probably be hundreds of logging calls that wouldn't
>>>> create an object because filtering didn't pass, thus compensating for the
>>>> extra cost of allocating the objects and immediately discarding them.
>>>> OTOH, doing
>>>>
>>>> if (logger.isDebugEnabled()) {
>>>> logger.debug(new StringFormattedMessage(format, param));
>>>> }
>>>>
>>>> would probably perform better than
>>>>
>>>> logger.debug(StringFormattedMessage.class, format, param);
>>>>
>>>> Ralph
>>>>
>>>>
>>>> On Oct 5, 2012, at 8:35 AM, Gary Gregory wrote:
>>>>
>>>> On Thu, Oct 4, 2012 at 10:54 PM, Ralph Goers <rg...@apache.org> wrote:
>>>>
>>>>> Yup. That is what I would expect. However, it probably requires a
>>>>> Message that has a constructor that accepts a Throwable and an object
>>>>> array, which means we would probably want a new interface as a marker.
>>>>>
>>>>
>>>> So would reflection be used at runtime to instantiate the message?
>>>> Wouldn't that be a performance hit?
>>>>
>>>> We could just provide APIs in AbstractLogger for the built-in message
>>>> classes that do the instance creation w/o reflection.
>>>>
>>>> Thoughts?
>>>>
>>>> Gary
>>>>
>>>>
>>>>> Ralph
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On Oct 4, 2012, at 7:18 PM, Paul Benedict <pb...@apache.org>
>>>>> wrote:
>>>>>
>>>>> Ooops. I meant this:
>>>>>
>>>>> logger.debug(Class<? extends Message> m, Throwable t, Object...
>>>>> messageParams);
>>>>>
>>>>> The point was to pass in the Class of the Message so it doesn't get
>>>>> instantiated unless logging is going to occur.
>>>>>
>>>>> Paul
>>>>>
>>>>> On Thu, Oct 4, 2012 at 9:12 PM, Gary Gregory <ga...@gmail.com>wrote:
>>>>>
>>>>>> On Thu, Oct 4, 2012 at 10:06 PM, Paul Benedict <pb...@apache.org>wrote:
>>>>>>
>>>>>>> On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory <garydgregory@gmail.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pbenedict@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.
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>
>>>>>>>> So instead of:
>>>>>>>>
>>>>>>>> this.logger.debug(new StringFormattedMessage(format, values), t);
>>>>>>>>
>>>>>>>> I would do:
>>>>>>>>
>>>>>>>> this.logger.debug(StringFormattedMessage.class, t, format, values);
>>>>>>>>
>>>>>>>>
>>>>>>> I was thinking of adding this signature:
>>>>>>> logger.debug(Message m, Throwable t, Object... messageParams);
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>
>>>>>> Pardon me for being dense, but how does that help in the case of my
>>>>>> examples?
>>>>>>
>>>>>> Thank you in advance for clarifying,
>>>>>> Gary
>>>>>>
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: Exception not logged?
Posted by Ralph Goers <ra...@dslextreme.com>.
What you have done is separate the format from the data, If you look at AbstractLogger you will notice that the logging information (format string and parameters) is all grouped together . The LogEvent only contains a Message, not format strings and parameters.
To do what you are suggesting, logger.debug would have to retrieve the Message and then do something with the params. It can't modify the Message object by storing the params in it as that isn't thread-safe, and passing the parameters to the LogEvent leads to other problems.
What might make more sense would to use a MessageFactory to bypass the cost of reflection. But then the API would need to reference the factory somehow.
Ralph
On Oct 5, 2012, at 1:11 PM, Paul Benedict wrote:
> IMO, I thought all Message implements should be stateless. Maybe that should be part of the Message interface contract anyway, regardless of my idea.
>
> Paul
>
> On Fri, Oct 5, 2012 at 3:06 PM, Gary Gregory <ga...@gmail.com> wrote:
> That's clever but... when happens when multiple threads call run(String)? We'd need to make sure all Message implementations are stateless.
>
> I'm not sure I'd want to keep both places in the code in sync too. Every time I want to fiddle with a message format, I have to make sure both spots match. Seems to painful to me. An interesting thought though, but it does not make my life easier as a v2 user...
>
> Gary
>
> On Fri, Oct 5, 2012 at 2:53 PM, Paul Benedict <pb...@apache.org> wrote:
> After reading this email, it occurred to me that Messages/Formats are typically static. Once instantiated, there is really no need to instantiate it over and over.
>
> Rather than specifying the Class<?>, perhaps there should be a registration feature. Maybe like this:
>
> public class MyApp {
> public static Logger logger;
> static {
> logger.registerMessage("messagekey", new StringFormattedMessage("%s"));
> }
>
> public void run(String param) {
> logger.debug("messagekey", param);
> }
> }
>
> Paul
>
>
> On Fri, Oct 5, 2012 at 1:03 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> I updated ReflectionComparison to include comparing creating the object via "new" and via reflection.
>
> Timer NewObject stopped. Elapsed time: 0.019149000 seconds Average per iteration: 0.000000019 seconds
> Timer ReflectionObject stopped. Elapsed time: 0.171598000 seconds Average per iteration: 0.000000171 seconds
>
> So reflection definitely is noticeably slower, but this is only going to occur after filtering has passed and is probably a good tradeoff for avoiding calling "new" in the application until it is actually needed. For example, there would probably be hundreds of logging calls that wouldn't create an object because filtering didn't pass, thus compensating for the extra cost of allocating the objects and immediately discarding them. OTOH, doing
>
> if (logger.isDebugEnabled()) {
> logger.debug(new StringFormattedMessage(format, param));
> }
>
> would probably perform better than
>
> logger.debug(StringFormattedMessage.class, format, param);
>
> Ralph
>
>
> On Oct 5, 2012, at 8:35 AM, Gary Gregory wrote:
>
>> On Thu, Oct 4, 2012 at 10:54 PM, Ralph Goers <rg...@apache.org> wrote:
>> Yup. That is what I would expect. However, it probably requires a Message that has a constructor that accepts a Throwable and an object array, which means we would probably want a new interface as a marker.
>>
>> So would reflection be used at runtime to instantiate the message? Wouldn't that be a performance hit?
>>
>> We could just provide APIs in AbstractLogger for the built-in message classes that do the instance creation w/o reflection.
>>
>> Thoughts?
>>
>> Gary
>>
>>
>> Ralph
>>
>> Sent from my iPad
>>
>> On Oct 4, 2012, at 7:18 PM, Paul Benedict <pb...@apache.org> wrote:
>>
>>> Ooops. I meant this:
>>>
>>> logger.debug(Class<? extends Message> m, Throwable t, Object... messageParams);
>>>
>>> The point was to pass in the Class of the Message so it doesn't get instantiated unless logging is going to occur.
>>>
>>> Paul
>>>
>>> On Thu, Oct 4, 2012 at 9:12 PM, Gary Gregory <ga...@gmail.com> wrote:
>>> On Thu, Oct 4, 2012 at 10:06 PM, Paul Benedict <pb...@apache.org> wrote:
>>> On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory <ga...@gmail.com> wrote:
>>> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pb...@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.
>>>
>>> Thoughts?
>>>
>>> So instead of:
>>>
>>> this.logger.debug(new StringFormattedMessage(format, values), t);
>>>
>>> I would do:
>>>
>>> this.logger.debug(StringFormattedMessage.class, t, format, values);
>>>
>>>
>>> I was thinking of adding this signature:
>>> logger.debug(Message m, Throwable t, Object... messageParams);
>>>
>>> Thoughts?
>>>
>>> Pardon me for being dense, but how does that help in the case of my examples?
>>>
>>> Thank you in advance for clarifying,
>>> Gary
>>>
>>> Paul
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>>> Spring Batch in Action: http://bit.ly/bqpbCK
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Re: Exception not logged?
Posted by Paul Benedict <pb...@apache.org>.
IMO, I thought all Message implements should be stateless. Maybe that
should be part of the Message interface contract anyway, regardless of my
idea.
Paul
On Fri, Oct 5, 2012 at 3:06 PM, Gary Gregory <ga...@gmail.com> wrote:
> That's clever but... when happens when multiple threads call run(String)?
> We'd need to make sure all Message implementations are stateless.
>
> I'm not sure I'd want to keep both places in the code in sync too. Every
> time I want to fiddle with a message format, I have to make sure both spots
> match. Seems to painful to me. An interesting thought though, but it does
> not make my life easier as a v2 user...
>
> Gary
>
> On Fri, Oct 5, 2012 at 2:53 PM, Paul Benedict <pb...@apache.org>wrote:
>
>> After reading this email, it occurred to me that Messages/Formats are
>> typically static. Once instantiated, there is really no need to instantiate
>> it over and over.
>>
>> Rather than specifying the Class<?>, perhaps there should be a
>> registration feature. Maybe like this:
>>
>> public class MyApp {
>> public static Logger logger;
>> static {
>> logger.registerMessage("messagekey", new
>> StringFormattedMessage("%s"));
>> }
>>
>> public void run(String param) {
>> logger.debug("messagekey", param);
>> }
>> }
>>
>> Paul
>>
>>
>> On Fri, Oct 5, 2012 at 1:03 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>>
>>> I updated ReflectionComparison to include comparing creating the object
>>> via "new" and via reflection.
>>>
>>> Timer NewObject stopped. Elapsed time: 0.019149000 seconds Average per
>>> iteration: 0.000000019 seconds
>>> Timer ReflectionObject stopped. Elapsed time: 0.171598000 seconds
>>> Average per iteration: 0.000000171 seconds
>>>
>>> So reflection definitely is noticeably slower, but this is only going to
>>> occur after filtering has passed and is probably a good tradeoff for
>>> avoiding calling "new" in the application until it is actually needed. For
>>> example, there would probably be hundreds of logging calls that wouldn't
>>> create an object because filtering didn't pass, thus compensating for the
>>> extra cost of allocating the objects and immediately discarding them.
>>> OTOH, doing
>>>
>>> if (logger.isDebugEnabled()) {
>>> logger.debug(new StringFormattedMessage(format, param));
>>> }
>>>
>>> would probably perform better than
>>>
>>> logger.debug(StringFormattedMessage.class, format, param);
>>>
>>> Ralph
>>>
>>>
>>> On Oct 5, 2012, at 8:35 AM, Gary Gregory wrote:
>>>
>>> On Thu, Oct 4, 2012 at 10:54 PM, Ralph Goers <rg...@apache.org> wrote:
>>>
>>>> Yup. That is what I would expect. However, it probably requires a
>>>> Message that has a constructor that accepts a Throwable and an object
>>>> array, which means we would probably want a new interface as a marker.
>>>>
>>>
>>> So would reflection be used at runtime to instantiate the message?
>>> Wouldn't that be a performance hit?
>>>
>>> We could just provide APIs in AbstractLogger for the built-in message
>>> classes that do the instance creation w/o reflection.
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>>
>>>> Ralph
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Oct 4, 2012, at 7:18 PM, Paul Benedict <pb...@apache.org> wrote:
>>>>
>>>> Ooops. I meant this:
>>>>
>>>> logger.debug(Class<? extends Message> m, Throwable t, Object...
>>>> messageParams);
>>>>
>>>> The point was to pass in the Class of the Message so it doesn't get
>>>> instantiated unless logging is going to occur.
>>>>
>>>> Paul
>>>>
>>>> On Thu, Oct 4, 2012 at 9:12 PM, Gary Gregory <ga...@gmail.com>wrote:
>>>>
>>>>> On Thu, Oct 4, 2012 at 10:06 PM, Paul Benedict <pb...@apache.org>wrote:
>>>>>
>>>>>> On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory <ga...@gmail.com>wrote:
>>>>>>
>>>>>>> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pb...@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.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>
>>>>>>> So instead of:
>>>>>>>
>>>>>>> this.logger.debug(new StringFormattedMessage(format, values), t);
>>>>>>>
>>>>>>> I would do:
>>>>>>>
>>>>>>> this.logger.debug(StringFormattedMessage.class, t, format, values);
>>>>>>>
>>>>>>>
>>>>>> I was thinking of adding this signature:
>>>>>> logger.debug(Message m, Throwable t, Object... messageParams);
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>
>>>>> Pardon me for being dense, but how does that help in the case of my
>>>>> examples?
>>>>>
>>>>> Thank you in advance for clarifying,
>>>>> Gary
>>>>>
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
>
Re: Exception not logged?
Posted by Gary Gregory <ga...@gmail.com>.
That's clever but... when happens when multiple threads call run(String)?
We'd need to make sure all Message implementations are stateless.
I'm not sure I'd want to keep both places in the code in sync too. Every
time I want to fiddle with a message format, I have to make sure both spots
match. Seems to painful to me. An interesting thought though, but it does
not make my life easier as a v2 user...
Gary
On Fri, Oct 5, 2012 at 2:53 PM, Paul Benedict <pb...@apache.org> wrote:
> After reading this email, it occurred to me that Messages/Formats are
> typically static. Once instantiated, there is really no need to instantiate
> it over and over.
>
> Rather than specifying the Class<?>, perhaps there should be a
> registration feature. Maybe like this:
>
> public class MyApp {
> public static Logger logger;
> static {
> logger.registerMessage("messagekey", new StringFormattedMessage("%s"));
> }
>
> public void run(String param) {
> logger.debug("messagekey", param);
> }
> }
>
> Paul
>
>
> On Fri, Oct 5, 2012 at 1:03 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> I updated ReflectionComparison to include comparing creating the object
>> via "new" and via reflection.
>>
>> Timer NewObject stopped. Elapsed time: 0.019149000 seconds Average per
>> iteration: 0.000000019 seconds
>> Timer ReflectionObject stopped. Elapsed time: 0.171598000 seconds Average
>> per iteration: 0.000000171 seconds
>>
>> So reflection definitely is noticeably slower, but this is only going to
>> occur after filtering has passed and is probably a good tradeoff for
>> avoiding calling "new" in the application until it is actually needed. For
>> example, there would probably be hundreds of logging calls that wouldn't
>> create an object because filtering didn't pass, thus compensating for the
>> extra cost of allocating the objects and immediately discarding them.
>> OTOH, doing
>>
>> if (logger.isDebugEnabled()) {
>> logger.debug(new StringFormattedMessage(format, param));
>> }
>>
>> would probably perform better than
>>
>> logger.debug(StringFormattedMessage.class, format, param);
>>
>> Ralph
>>
>>
>> On Oct 5, 2012, at 8:35 AM, Gary Gregory wrote:
>>
>> On Thu, Oct 4, 2012 at 10:54 PM, Ralph Goers <rg...@apache.org> wrote:
>>
>>> Yup. That is what I would expect. However, it probably requires a
>>> Message that has a constructor that accepts a Throwable and an object
>>> array, which means we would probably want a new interface as a marker.
>>>
>>
>> So would reflection be used at runtime to instantiate the message?
>> Wouldn't that be a performance hit?
>>
>> We could just provide APIs in AbstractLogger for the built-in message
>> classes that do the instance creation w/o reflection.
>>
>> Thoughts?
>>
>> Gary
>>
>>
>>> Ralph
>>>
>>> Sent from my iPad
>>>
>>> On Oct 4, 2012, at 7:18 PM, Paul Benedict <pb...@apache.org> wrote:
>>>
>>> Ooops. I meant this:
>>>
>>> logger.debug(Class<? extends Message> m, Throwable t, Object...
>>> messageParams);
>>>
>>> The point was to pass in the Class of the Message so it doesn't get
>>> instantiated unless logging is going to occur.
>>>
>>> Paul
>>>
>>> On Thu, Oct 4, 2012 at 9:12 PM, Gary Gregory <ga...@gmail.com>wrote:
>>>
>>>> On Thu, Oct 4, 2012 at 10:06 PM, Paul Benedict <pb...@apache.org>wrote:
>>>>
>>>>> On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory <ga...@gmail.com>wrote:
>>>>>
>>>>>> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pb...@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.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>
>>>>>> So instead of:
>>>>>>
>>>>>> this.logger.debug(new StringFormattedMessage(format, values), t);
>>>>>>
>>>>>> I would do:
>>>>>>
>>>>>> this.logger.debug(StringFormattedMessage.class, t, format, values);
>>>>>>
>>>>>>
>>>>> I was thinking of adding this signature:
>>>>> logger.debug(Message m, Throwable t, Object... messageParams);
>>>>>
>>>>> Thoughts?
>>>>>
>>>>
>>>> Pardon me for being dense, but how does that help in the case of my
>>>> examples?
>>>>
>>>> Thank you in advance for clarifying,
>>>> Gary
>>>>
>>>>>
>>>>> Paul
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: Exception not logged?
Posted by Paul Benedict <pb...@apache.org>.
After reading this email, it occurred to me that Messages/Formats are
typically static. Once instantiated, there is really no need to instantiate
it over and over.
Rather than specifying the Class<?>, perhaps there should be a registration
feature. Maybe like this:
public class MyApp {
public static Logger logger;
static {
logger.registerMessage("messagekey", new StringFormattedMessage("%s"));
}
public void run(String param) {
logger.debug("messagekey", param);
}
}
Paul
On Fri, Oct 5, 2012 at 1:03 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> I updated ReflectionComparison to include comparing creating the object
> via "new" and via reflection.
>
> Timer NewObject stopped. Elapsed time: 0.019149000 seconds Average per
> iteration: 0.000000019 seconds
> Timer ReflectionObject stopped. Elapsed time: 0.171598000 seconds Average
> per iteration: 0.000000171 seconds
>
> So reflection definitely is noticeably slower, but this is only going to
> occur after filtering has passed and is probably a good tradeoff for
> avoiding calling "new" in the application until it is actually needed. For
> example, there would probably be hundreds of logging calls that wouldn't
> create an object because filtering didn't pass, thus compensating for the
> extra cost of allocating the objects and immediately discarding them.
> OTOH, doing
>
> if (logger.isDebugEnabled()) {
> logger.debug(new StringFormattedMessage(format, param));
> }
>
> would probably perform better than
>
> logger.debug(StringFormattedMessage.class, format, param);
>
> Ralph
>
>
> On Oct 5, 2012, at 8:35 AM, Gary Gregory wrote:
>
> On Thu, Oct 4, 2012 at 10:54 PM, Ralph Goers <rg...@apache.org> wrote:
>
>> Yup. That is what I would expect. However, it probably requires a
>> Message that has a constructor that accepts a Throwable and an object
>> array, which means we would probably want a new interface as a marker.
>>
>
> So would reflection be used at runtime to instantiate the message?
> Wouldn't that be a performance hit?
>
> We could just provide APIs in AbstractLogger for the built-in message
> classes that do the instance creation w/o reflection.
>
> Thoughts?
>
> Gary
>
>
>> Ralph
>>
>> Sent from my iPad
>>
>> On Oct 4, 2012, at 7:18 PM, Paul Benedict <pb...@apache.org> wrote:
>>
>> Ooops. I meant this:
>>
>> logger.debug(Class<? extends Message> m, Throwable t, Object...
>> messageParams);
>>
>> The point was to pass in the Class of the Message so it doesn't get
>> instantiated unless logging is going to occur.
>>
>> Paul
>>
>> On Thu, Oct 4, 2012 at 9:12 PM, Gary Gregory <ga...@gmail.com>wrote:
>>
>>> On Thu, Oct 4, 2012 at 10:06 PM, Paul Benedict <pb...@apache.org>wrote:
>>>
>>>> On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory <ga...@gmail.com>wrote:
>>>>
>>>>> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pb...@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.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>
>>>>> So instead of:
>>>>>
>>>>> this.logger.debug(new StringFormattedMessage(format, values), t);
>>>>>
>>>>> I would do:
>>>>>
>>>>> this.logger.debug(StringFormattedMessage.class, t, format, values);
>>>>>
>>>>>
>>>> I was thinking of adding this signature:
>>>> logger.debug(Message m, Throwable t, Object... messageParams);
>>>>
>>>> Thoughts?
>>>>
>>>
>>> Pardon me for being dense, but how does that help in the case of my
>>> examples?
>>>
>>> Thank you in advance for clarifying,
>>> Gary
>>>
>>>>
>>>> Paul
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
>
>
>
Re: Exception not logged?
Posted by Ralph Goers <ra...@dslextreme.com>.
I updated ReflectionComparison to include comparing creating the object via "new" and via reflection.
Timer NewObject stopped. Elapsed time: 0.019149000 seconds Average per iteration: 0.000000019 seconds
Timer ReflectionObject stopped. Elapsed time: 0.171598000 seconds Average per iteration: 0.000000171 seconds
So reflection definitely is noticeably slower, but this is only going to occur after filtering has passed and is probably a good tradeoff for avoiding calling "new" in the application until it is actually needed. For example, there would probably be hundreds of logging calls that wouldn't create an object because filtering didn't pass, thus compensating for the extra cost of allocating the objects and immediately discarding them. OTOH, doing
if (logger.isDebugEnabled()) {
logger.debug(new StringFormattedMessage(format, param));
}
would probably perform better than
logger.debug(StringFormattedMessage.class, format, param);
Ralph
On Oct 5, 2012, at 8:35 AM, Gary Gregory wrote:
> On Thu, Oct 4, 2012 at 10:54 PM, Ralph Goers <rg...@apache.org> wrote:
> Yup. That is what I would expect. However, it probably requires a Message that has a constructor that accepts a Throwable and an object array, which means we would probably want a new interface as a marker.
>
> So would reflection be used at runtime to instantiate the message? Wouldn't that be a performance hit?
>
> We could just provide APIs in AbstractLogger for the built-in message classes that do the instance creation w/o reflection.
>
> Thoughts?
>
> Gary
>
>
> Ralph
>
> Sent from my iPad
>
> On Oct 4, 2012, at 7:18 PM, Paul Benedict <pb...@apache.org> wrote:
>
>> Ooops. I meant this:
>>
>> logger.debug(Class<? extends Message> m, Throwable t, Object... messageParams);
>>
>> The point was to pass in the Class of the Message so it doesn't get instantiated unless logging is going to occur.
>>
>> Paul
>>
>> On Thu, Oct 4, 2012 at 9:12 PM, Gary Gregory <ga...@gmail.com> wrote:
>> On Thu, Oct 4, 2012 at 10:06 PM, Paul Benedict <pb...@apache.org> wrote:
>> On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory <ga...@gmail.com> wrote:
>> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pb...@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.
>>
>> Thoughts?
>>
>> So instead of:
>>
>> this.logger.debug(new StringFormattedMessage(format, values), t);
>>
>> I would do:
>>
>> this.logger.debug(StringFormattedMessage.class, t, format, values);
>>
>>
>> I was thinking of adding this signature:
>> logger.debug(Message m, Throwable t, Object... messageParams);
>>
>> Thoughts?
>>
>> Pardon me for being dense, but how does that help in the case of my examples?
>>
>> Thank you in advance for clarifying,
>> Gary
>>
>> Paul
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Re: Exception not logged?
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Oct 4, 2012 at 10:54 PM, Ralph Goers <rg...@apache.org> wrote:
> Yup. That is what I would expect. However, it probably requires a Message
> that has a constructor that accepts a Throwable and an object array, which
> means we would probably want a new interface as a marker.
>
So would reflection be used at runtime to instantiate the message? Wouldn't
that be a performance hit?
We could just provide APIs in AbstractLogger for the built-in message
classes that do the instance creation w/o reflection.
Thoughts?
Gary
> Ralph
>
> Sent from my iPad
>
> On Oct 4, 2012, at 7:18 PM, Paul Benedict <pb...@apache.org> wrote:
>
> Ooops. I meant this:
>
> logger.debug(Class<? extends Message> m, Throwable t, Object...
> messageParams);
>
> The point was to pass in the Class of the Message so it doesn't get
> instantiated unless logging is going to occur.
>
> Paul
>
> On Thu, Oct 4, 2012 at 9:12 PM, Gary Gregory <ga...@gmail.com>wrote:
>
>> On Thu, Oct 4, 2012 at 10:06 PM, Paul Benedict <pb...@apache.org>wrote:
>>
>>> On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory <ga...@gmail.com>wrote:
>>>
>>>> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pb...@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.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>
>>>> So instead of:
>>>>
>>>> this.logger.debug(new StringFormattedMessage(format, values), t);
>>>>
>>>> I would do:
>>>>
>>>> this.logger.debug(StringFormattedMessage.class, t, format, values);
>>>>
>>>>
>>> I was thinking of adding this signature:
>>> logger.debug(Message m, Throwable t, Object... messageParams);
>>>
>>> Thoughts?
>>>
>>
>> Pardon me for being dense, but how does that help in the case of my
>> examples?
>>
>> Thank you in advance for clarifying,
>> Gary
>>
>>>
>>> Paul
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: Exception not logged?
Posted by Ralph Goers <rg...@apache.org>.
Yup. That is what I would expect. However, it probably requires a Message that has a constructor that accepts a Throwable and an object array, which means we would probably want a new interface as a marker.
Ralph
Sent from my iPad
On Oct 4, 2012, at 7:18 PM, Paul Benedict <pb...@apache.org> wrote:
> Ooops. I meant this:
>
> logger.debug(Class<? extends Message> m, Throwable t, Object... messageParams);
>
> The point was to pass in the Class of the Message so it doesn't get instantiated unless logging is going to occur.
>
> Paul
>
> On Thu, Oct 4, 2012 at 9:12 PM, Gary Gregory <ga...@gmail.com> wrote:
>> On Thu, Oct 4, 2012 at 10:06 PM, Paul Benedict <pb...@apache.org> wrote:
>>> On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pb...@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.
>>>>>
>>>>> Thoughts?
>>>>
>>>>
>>>> So instead of:
>>>>
>>>> this.logger.debug(new StringFormattedMessage(format, values), t);
>>>>
>>>> I would do:
>>>>
>>>> this.logger.debug(StringFormattedMessage.class, t, format, values);
>>>
>>> I was thinking of adding this signature:
>>> logger.debug(Message m, Throwable t, Object... messageParams);
>>>
>>> Thoughts?
>>
>> Pardon me for being dense, but how does that help in the case of my examples?
>>
>> Thank you in advance for clarifying,
>> Gary
>>>
>>> Paul
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
Re: Exception not logged?
Posted by Paul Benedict <pb...@apache.org>.
Ooops. I meant this:
logger.debug(Class<? extends Message> m, Throwable t, Object...
messageParams);
The point was to pass in the Class of the Message so it doesn't get
instantiated unless logging is going to occur.
Paul
On Thu, Oct 4, 2012 at 9:12 PM, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, Oct 4, 2012 at 10:06 PM, Paul Benedict <pb...@apache.org>wrote:
>
>> On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory <ga...@gmail.com>wrote:
>>
>>> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pb...@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.
>>>>
>>>> Thoughts?
>>>>
>>>
>>> So instead of:
>>>
>>> this.logger.debug(new StringFormattedMessage(format, values), t);
>>>
>>> I would do:
>>>
>>> this.logger.debug(StringFormattedMessage.class, t, format, values);
>>>
>>>
>> I was thinking of adding this signature:
>> logger.debug(Message m, Throwable t, Object... messageParams);
>>
>> Thoughts?
>>
>
> Pardon me for being dense, but how does that help in the case of my
> examples?
>
> Thank you in advance for clarifying,
> Gary
>
>>
>> Paul
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
>
Re: Exception not logged?
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Oct 4, 2012 at 10:06 PM, Paul Benedict <pb...@apache.org> wrote:
> On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory <ga...@gmail.com>wrote:
>
>> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pb...@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.
>>>
>>> Thoughts?
>>>
>>
>> So instead of:
>>
>> this.logger.debug(new StringFormattedMessage(format, values), t);
>>
>> I would do:
>>
>> this.logger.debug(StringFormattedMessage.class, t, format, values);
>>
>>
> I was thinking of adding this signature:
> logger.debug(Message m, Throwable t, Object... messageParams);
>
> Thoughts?
>
Pardon me for being dense, but how does that help in the case of my
examples?
Thank you in advance for clarifying,
Gary
>
> Paul
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: Exception not logged?
Posted by Paul Benedict <pb...@apache.org>.
On Thu, Oct 4, 2012 at 7:24 PM, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pb...@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.
>>
>> Thoughts?
>>
>
> So instead of:
>
> this.logger.debug(new StringFormattedMessage(format, values), t);
>
> I would do:
>
> this.logger.debug(StringFormattedMessage.class, t, format, values);
>
>
I was thinking of adding this signature:
logger.debug(Message m, Throwable t, Object... messageParams);
Thoughts?
Paul
Re: Exception not logged?
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pb...@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.
>
> Thoughts?
>
So instead of:
this.logger.debug(new StringFormattedMessage(format, values), t);
I would do:
this.logger.debug(StringFormattedMessage.class, t, format, values);
Which then I might as well do:
this.logger.methodNameTbd(t, format, values);
?
G
>
> Paul
>
>
> On Thu, Oct 4, 2012 at 4:51 PM, Ralph Goers <ra...@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 <ra...@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: Exception not logged?
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Oct 4, 2012 at 5:55 PM, Paul Benedict <pb...@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 <ra...@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 <ra...@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: Exception not logged?
Posted by Paul Benedict <pb...@apache.org>.
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.
Thoughts?
Paul
On Thu, Oct 4, 2012 at 4:51 PM, Ralph Goers <ra...@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 <ra...@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
>
>
>
Re: Exception not logged?
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@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: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Re: Exception not logged?
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Oct 4, 2012 at 5:10 PM, Ralph Goers <ra...@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: Exception not logged?
Posted by Ralph Goers <ra...@dslextreme.com>.
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);
}
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: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Re: Exception not logged?
Posted by Gary Gregory <ga...@gmail.com>.
There's one for the FAQ! Thanks.
Gary
On Oct 4, 2012, at 17:05, Ralph Goers <ra...@dslextreme.com> wrote:
Logback automatically includes %ex at the end of the pattern if you don't
explicitly and you have to specify %noEx to turn it off.
In Log4j 2 you have to explicitly specify one of %ex, %xEx or %rEx to the
end of the pattern. There is no equivalent to %noEx since you have to
explicitly include it.
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: garydgregory@gmail.com | ggregory@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
Re: Exception not logged?
Posted by Ralph Goers <ra...@dslextreme.com>.
Logback automatically includes %ex at the end of the pattern if you don't explicitly and you have to specify %noEx to turn it off.
In Log4j 2 you have to explicitly specify one of %ex, %xEx or %rEx to the end of the pattern. There is no equivalent to %noEx since you have to explicitly include it.
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: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory