[slf4j-dev] svn commit: r1155 - in slf4j/trunk/slf4j-ext/src/main/java/org/slf4j: agent instrumentation

[Ralph Goers]

XLogger just provides some basic "extended" methods in a standardized 
way. I would prefer that rather than use _log.debug you would use 
XLogger.entry as it makes filtering them easier. 

In our code we manually add entry, exit, caught, etc. to everything 
except simple getters and setters. The overhead of this when they are 
not enabled is extremely small. But, as is noted in many AOP books, it 
is somewhat distracting and is kind of a pain to have to do manually.  
But the benefit is enormous. In development it is a great learning tool 
and is helpful in debugging. In production we will sometimes turn it on 
but only for a small set of classes as the volume of output is way too 
large. Usually we will enable the other debug messages but leave flow 
tracing disabled.

What would be better, if it is possible, is to inject the logging 
dynamically when needed and completely remove it when not, eliminating 
any performance overhead at all.

Ralph

Thorbjørn Ravn Andersen wrote:
> Ralph Goers skrev:
>   
>> Thanks,
>>
>> I'm quite interested in this, but not only for entering and exiting but 
>> eventually for other logging as well.  However,  I wouldn't want it in 
>> all classes. I'd prefer to see additional configuration to define which 
>> classes should be instrumented.
>>   
>>     
> You are welcome.
>
> Basically, all this does is inserting a "if (_log.isDebugEnabled()) 
> _log.debug("entering XXX with arguments Y=..., Z=....")" and a 
> corresponding exit logger to each method. It _IS_ simple and I do not 
> want to build it to be some large instrumentation framework.    It is 
> just to allow people to very easily get extra information - a quick win 
> - without having to do a lot of stuff.
>
> A much better approach in the long run would be to build this within an 
> aspect framework (and keep the original agent).  AspectJ allows for load 
> time instrumentation (as I did here), but I have not had the need yet to 
> make this work.  Apparently this is something that every aspect oriented 
> programming tutorial says is easy to do, but not very often spell out 
> how to do.
>
> My question now is, what is the problem you want to solve with XLogger?
>
>