commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [general] logging
Date Mon, 30 Aug 2004 09:22:48 GMT
On 27 Aug 2004, at 21:17, Henri Yandell wrote:
> +1. I don't see any advantage to the commons-monitor approach as it 
> would
> still involve a dependency and would probably be harder to code than
> simple logging.
>
> Is there an easy way to produce a jar stripped of its logging parts? 
> Any
> of the bytecode-manip/aspect systems that could do it?

depends on what you mean by stripped. i'm not sure that this is the 
angle to approach the problem from. i'd like to say a few words on 
classloading issues before moving on to the way i'd approach the 
problem.

the main reason why there are lots of classloader issues reported seems 
to be that there are a lot of folks out there who are used to modern 
containers taking all the pain out of classloading. a generation or two 
ago, you needed to have an understanding of classloader issues. modern 
containers are much better. most of the classloader issues reported are 
easily solved by tinkering with the classpath. given the complexity of 
the problem and the fact that commons-logging is used by many 
containers, it does a reasonable job and i'd be very surprised if a 
better general solution could be found. (i would prefer the option to 
be able to switch off reporting configuration exceptions (at the 
command line) since i (now) agree with ceki that a failure in the 
logging framework should not stop a library working.)

the way i'd approach the problem is that the real cause of problems is 
that commons-logging is too big and too general. with hindsight, a much 
more minimal library (2 public classes only) together with an optional 
jar of implementations would have been better.

what is really needed are a variety of implementations for different 
circumstances. for example:

1 a minimal footprint implementation logging
2 a J2SE implementation without the tricky J2EE classloader stuff
3 a no-logging implementation
4 a monitor-adapted implementation
5 single logging system only implementations

using replacement, binary compatible jars containing re-implementation 
have been advocated many times but don't seem very popular. one 
possible reason for this is the fact that this approach requires users 
to solve their own classloader issues.

i am suspect that it would be possible to use byte-code engineering to 
wire up alternative implementations. the logging code wouldn't be 
stripped but rather a new implementation would be wired in. of course, 
the problem with this is that users would need to re-enhance the 
library rather than reconfigure if they wanted to change targets.

anyone interested in pursuing this idea?

- robert


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


Mime
View raw message