On Sep 25, 2012, at 8:42 AM, Gary Gregory wrote:
> On Tue, Sep 25, 2012 at 11:03 AM, Ralph Goers <ralph.go...@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 <ralph.go...@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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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
