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/09/25 01:38:13 UTC
Logger and throwables
Hi All,
Most of the time, I now do:
logger.error(throwable.toString(), throwable);
I do this instead of
logger.error(throwable.getMessage(), throwable)
in case the message is null.
But I'd rather simply say:
logger.error(throwable)
Same idea for other levels.
Thoughts?
Gary
--
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: Logger and throwables
Posted by Ralph Goers <ra...@dslextreme.com>.
On Sep 25, 2012, at 8:42 AM, Gary Gregory wrote:
> On Tue, Sep 25, 2012 at 11:03 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> Can you look at the context of where you like to write logger.error(Throwable) and see if it is at all possible to do something with annotations there? For example, in a catch statement could you do
>
> catch (@log UnsupportedOperationException ex)
>
> This kind of use of annotations is something I've thought about and why I created LOG4J2-33.
>
> I love it!
>
> This is the kind of innovation I should have in 2.0!
>
> My tweaks for 2.0 would be to change: Log.get() to Logger.get() because you are getting a Logger instance.
I didn't realize you were referring to the project mentioned in LOG4J2-33.
>
> My additional tweak would be to allow for per-instance Loggers. For finer grained control of massive logging output, our users can control logging of components based on their names.
>
> For example:
>
> new MyComponent("name")
>
> where the ctor does:
>
> MyComponent(String name) {
> this.logger = Logger.getLogger(MyComponent.class.getName() + "." + name;
> this.name = name;
> }
This could easily be possible now just by creating a new ClassMethodFilter as every LogEvent already has the Class and method name in it. However, that isn't necessarily the fastest way to filter.
>
> How would that work with annotations? I guess it cannot :( I could say:
>
> @Loggable(instance=true)
> MyComponent(String name) {
> Logger.get().setName(MyComponent.class.getName() + "." + name)
> // or: avoid a class ref w:
> Logger.get().appendName("." + name)
> this.name = name;
> }
The problem with using the class and method name the way you are is that it will become very tedious to configure logging. That is why Loggers tend to be named on their classes but the configured loggers are some subset of the package.
If you want to start a subproject for annotation support I'd welcome that. You might also want to look around as I recall having seen a few other attempts to do something similar.
Ralph
>
> ?
>
> Gary
>
>
>
>
> Ralph
>
> On Sep 24, 2012, at 7:50 PM, Gary Gregory wrote:
>
>> The issue is closed so I'll comment here.
>>
>> Over all, my port to 2.0 went well, aside from some 1.2 compat issue I JIRA'd.
>>
>> Let's make a difference between binary compat and source compat. BC is no problem, calling error(), info(), and so on with a Throwable is the same as with 1.2.
>>
>> For SC, since you are recompiling, IMO, it is OK for a MAJOR release to be different and print the stack trace.
>>
>> It is just so nice to say debug(Throwable) and have the right thing (IMO again) happen.
>>
>> Having code say debug(throwable.toString(), throwable) is just... well lame :(
>>
>> The catching/throwing methods are so horribly named -- despite whatever history of inheriting genes from other logging frameworks -- that I shiver at the thought of using them. I had to read the Javadocs /carefully/. No big deal, I'll just ignore them. Then I am immediately wondering how these goofy APIs fit in with the other nicely named ones, error, warn, and so on. It's baffling to me. Must be my tired brain and body, I just moved ;)
>>
>> Gary
>>
>> On Mon, Sep 24, 2012 at 8:38 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>> See Log4j2-86 and Paul's concerns.
>>
>> Ralph
>>
>> On Sep 24, 2012, at 4:38 PM, Gary Gregory wrote:
>>
>>> Hi All,
>>>
>>> Most of the time, I now do:
>>>
>>> logger.error(throwable.toString(), throwable);
>>>
>>> I do this instead of
>>>
>>> logger.error(throwable.getMessage(), throwable)
>>>
>>> in case the message is null.
>>>
>>> But I'd rather simply say:
>>>
>>> logger.error(throwable)
>>>
>>> Same idea for other levels.
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>> --
>>> 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: Logger and throwables
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Sep 25, 2012 at 11:03 AM, Ralph Goers <ra...@dslextreme.com>wrote:
> Can you look at the context of where you like to write
> logger.error(Throwable) and see if it is at all possible to do something
> with annotations there? For example, in a catch statement could you do
>
> catch (@log UnsupportedOperationException ex)
>
> This kind of use of annotations is something I've thought about and why I
> created LOG4J2-33.
>
I love it!
This is the kind of innovation I should have in 2.0!
My tweaks for 2.0 would be to change: Log.get() to Logger.get() because you
are getting a Logger instance.
My additional tweak would be to allow for per-instance Loggers. For finer
grained control of massive logging output, our users can control logging of
components based on their names.
For example:
new MyComponent("name")
where the ctor does:
MyComponent(String name) {
this.logger = Logger.getLogger(MyComponent.class.getName() + "." + name;
this.name = name;
}
How would that work with annotations? I guess it cannot :( I could say:
@Loggable(instance=true)
MyComponent(String name) {
Logger.get().setName(MyComponent.class.getName() + "." + name)
// or: avoid a class ref w:
Logger.get().appendName("." + name)
this.name = name;
}
?
Gary
> Ralph
>
> On Sep 24, 2012, at 7:50 PM, Gary Gregory wrote:
>
> The issue is closed so I'll comment here.
>
> Over all, my port to 2.0 went well, aside from some 1.2 compat issue I
> JIRA'd.
>
> Let's make a difference between binary compat and source compat. BC is no
> problem, calling error(), info(), and so on with a Throwable is the same as
> with 1.2.
>
> For SC, since you are recompiling, IMO, it is OK for a MAJOR release to be
> different and print the stack trace.
>
> It is just so nice to say debug(Throwable) and have the right thing (IMO
> again) happen.
>
> Having code say debug(throwable.toString(), throwable) is just... well
> lame :(
>
> The catching/throwing methods are so horribly named -- despite whatever
> history of inheriting genes from other logging frameworks -- that I shiver
> at the thought of using them. I had to read the Javadocs /carefully/. No
> big deal, I'll just ignore them. Then I am immediately wondering how these
> goofy APIs fit in with the other nicely named ones, error, warn, and so on.
> It's baffling to me. Must be my tired brain and body, I just moved ;)
>
> Gary
>
> On Mon, Sep 24, 2012 at 8:38 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> See Log4j2-86 and Paul's concerns.
>>
>> Ralph
>>
>> On Sep 24, 2012, at 4:38 PM, Gary Gregory wrote:
>>
>> Hi All,
>>
>> Most of the time, I now do:
>>
>> logger.error(throwable.toString(), throwable);
>>
>> I do this instead of
>>
>> logger.error(throwable.getMessage(), throwable)
>>
>> in case the message is null.
>>
>> But I'd rather simply say:
>>
>> logger.error(throwable)
>>
>> Same idea for other levels.
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> 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: Logger and throwables
Posted by Ralph Goers <ra...@dslextreme.com>.
Can you look at the context of where you like to write logger.error(Throwable) and see if it is at all possible to do something with annotations there? For example, in a catch statement could you do
catch (@log UnsupportedOperationException ex)
This kind of use of annotations is something I've thought about and why I created LOG4J2-33.
Ralph
On Sep 24, 2012, at 7:50 PM, Gary Gregory wrote:
> The issue is closed so I'll comment here.
>
> Over all, my port to 2.0 went well, aside from some 1.2 compat issue I JIRA'd.
>
> Let's make a difference between binary compat and source compat. BC is no problem, calling error(), info(), and so on with a Throwable is the same as with 1.2.
>
> For SC, since you are recompiling, IMO, it is OK for a MAJOR release to be different and print the stack trace.
>
> It is just so nice to say debug(Throwable) and have the right thing (IMO again) happen.
>
> Having code say debug(throwable.toString(), throwable) is just... well lame :(
>
> The catching/throwing methods are so horribly named -- despite whatever history of inheriting genes from other logging frameworks -- that I shiver at the thought of using them. I had to read the Javadocs /carefully/. No big deal, I'll just ignore them. Then I am immediately wondering how these goofy APIs fit in with the other nicely named ones, error, warn, and so on. It's baffling to me. Must be my tired brain and body, I just moved ;)
>
> Gary
>
> On Mon, Sep 24, 2012 at 8:38 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> See Log4j2-86 and Paul's concerns.
>
> Ralph
>
> On Sep 24, 2012, at 4:38 PM, Gary Gregory wrote:
>
>> Hi All,
>>
>> Most of the time, I now do:
>>
>> logger.error(throwable.toString(), throwable);
>>
>> I do this instead of
>>
>> logger.error(throwable.getMessage(), throwable)
>>
>> in case the message is null.
>>
>> But I'd rather simply say:
>>
>> logger.error(throwable)
>>
>> Same idea for other levels.
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> 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: Logger and throwables
Posted by Ralph Goers <ra...@dslextreme.com>.
On Sep 25, 2012, at 8:36 AM, Noel Grandin wrote:
>
> On 2012-09-25 04:50, Gary Gregory wrote:
>> For SC, since you are recompiling, IMO, it is OK for a MAJOR release to be different and print the stack trace.
>>
>> It is just so nice to say debug(Throwable) and have the right thing (IMO again) happen.
>>
>> Having code say debug(throwable.toString(), throwable) is just... well lame :(
>>
>
> I tend to agree. I have these same methods in my own internal logging framework.
>
> Perhaps if there were convenience methods like
> void fatalException(Throwable t);
> void debugException(Throwable t);
> void warnException(Throwable t);
> void infoException(Throwable t);
> ??
>
> But then I like my API's to be quite wide, with lots of convenience methods :-)
I have no problem with these methods. Maybe they will make Gary happier ;-)
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Logger and throwables
Posted by Noel Grandin <no...@peralex.com>.
On 2012-09-25 04:50, Gary Gregory wrote:
> For SC, since you are recompiling, IMO, it is OK for a MAJOR release
> to be different and print the stack trace.
>
> It is just so nice to say debug(Throwable) and have the right thing
> (IMO again) happen.
>
> Having code say debug(throwable.toString(), throwable) is just... well
> lame :(
>
I tend to agree. I have these same methods in my own internal logging
framework.
Perhaps if there were convenience methods like
void fatalException(Throwable t);
void debugException(Throwable t);
void warnException(Throwable t);
void infoException(Throwable t);
??
But then I like my API's to be quite wide, with lots of convenience
methods :-)
Disclaimer: http://www.peralex.com/disclaimer.html
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Logger and throwables
Posted by Gary Gregory <ga...@gmail.com>.
The issue is closed so I'll comment here.
Over all, my port to 2.0 went well, aside from some 1.2 compat issue I
JIRA'd.
Let's make a difference between binary compat and source compat. BC is no
problem, calling error(), info(), and so on with a Throwable is the same as
with 1.2.
For SC, since you are recompiling, IMO, it is OK for a MAJOR release to be
different and print the stack trace.
It is just so nice to say debug(Throwable) and have the right thing (IMO
again) happen.
Having code say debug(throwable.toString(), throwable) is just... well lame
:(
The catching/throwing methods are so horribly named -- despite whatever
history of inheriting genes from other logging frameworks -- that I shiver
at the thought of using them. I had to read the Javadocs /carefully/. No
big deal, I'll just ignore them. Then I am immediately wondering how these
goofy APIs fit in with the other nicely named ones, error, warn, and so on.
It's baffling to me. Must be my tired brain and body, I just moved ;)
Gary
On Mon, Sep 24, 2012 at 8:38 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> See Log4j2-86 and Paul's concerns.
>
> Ralph
>
> On Sep 24, 2012, at 4:38 PM, Gary Gregory wrote:
>
> Hi All,
>
> Most of the time, I now do:
>
> logger.error(throwable.toString(), throwable);
>
> I do this instead of
>
> logger.error(throwable.getMessage(), throwable)
>
> in case the message is null.
>
> But I'd rather simply say:
>
> logger.error(throwable)
>
> Same idea for other levels.
>
> Thoughts?
>
> Gary
>
> --
> 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: Logger and throwables
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Sep 24, 2012 at 8:38 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> See Log4j2-86 and Paul's concerns.
>
Thank you for the pointer.
Gary
>
> Ralph
>
> On Sep 24, 2012, at 4:38 PM, Gary Gregory wrote:
>
> Hi All,
>
> Most of the time, I now do:
>
> logger.error(throwable.toString(), throwable);
>
> I do this instead of
>
> logger.error(throwable.getMessage(), throwable)
>
> in case the message is null.
>
> But I'd rather simply say:
>
> logger.error(throwable)
>
> Same idea for other levels.
>
> Thoughts?
>
> Gary
>
> --
> 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: Logger and throwables
Posted by Ralph Goers <ra...@dslextreme.com>.
See Log4j2-86 and Paul's concerns.
Ralph
On Sep 24, 2012, at 4:38 PM, Gary Gregory wrote:
> Hi All,
>
> Most of the time, I now do:
>
> logger.error(throwable.toString(), throwable);
>
> I do this instead of
>
> logger.error(throwable.getMessage(), throwable)
>
> in case the message is null.
>
> But I'd rather simply say:
>
> logger.error(throwable)
>
> Same idea for other levels.
>
> Thoughts?
>
> Gary
>
> --
> 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
>