commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <si...@ecnetwork.co.nz>
Subject [logging] bytecode engineering (was: Re: Commons Configuration - Digester Logging turned off)
Date Tue, 26 Oct 2004 21:40:19 GMT
On Tue, 2004-10-26 at 10:47, robert burrell donkin wrote:
> this might be a bit left field but i've been turning over the idea for 
> some time of using byte code engineering to wire up logging. one of the 
> problems with commons-logging is that it's nearly impossible to be all 
> thing to all people. the idea of running an enhancer at at a jar to 
> turn off logging (complete), switch to micro-thin logger or a non-j2ee 
> one appeals to me.

It does seem tempting from a performance point of view. I've always
thought it a bit odd that log4j goes to great lengths to optimise
performance, then commons-logging adds a layer of indirection on top
which is executed for every log statement (including those which are
filtered out). Modifying the bytecode to make direct calls to the
selected logging library seems nicer.

However I'm not sure how this can be done in practice. This means
ensuring every class that can potentially use logging must be loaded via
a custom classloader so that the bytecode can be modified as the .class
file is read from disk, right? 

When running a normal application with a "main" method, code would need
to ensure that the main thread's contextClassLoader is set to a custom
classloader before any classes (including static classes and the main
class specified on the commandline) are loaded. I'm no expert on this -
how could this be done?

The application would also need permission for "setContextClassLoader".
I don't know whether applets would have this permission.

When running code in a framework (eg tomcat), code loaded from shared
libraries would presumably have been modified to call directly to
whatever logging library is visible to the framework. But what about
when the components want to use a different logging library?

I'm not trying to argue against the idea of using bytecode modification
in commons-logging, just not sure how the above issues could be handled.
As I said, I'm no great expert in bytecode modification...

Cheers,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message