> -rw-r--r-- 1 544 cgu 29103 Aug 1 14:41 dist/lib/log4jME.jar
Hey, that's pretty cool. Especially in that it's using the log4j code base unchanged.
I was thinking something a bit more radical in it's impact on log4j's functionality, but probably much smaller in footprint.
Although I haven't tried it, it seems like we could create a new org.apache.log4j.Category class that turns things like addAppender and callAppenders into no-ops, sends all of the debug, error, fatal, info and warn messaged to stdout or stderr, and always returns the same singleton value for getInstance. If we wanted to be clever we might add the ability to turn logging on or off per category or message type.
Would support for the Category methods alone cover most everyone's use of log4j? If so we should be able to support that in a single class or so, probably well under 5k in binary, and still maintain API compatibility with log4j.
Does it really have to be that small? Does it really matter? If you’re trying
to make a version of log4j for embedded devices than that would be different.
I know Geir wanted to try that.
I think most people will have the full blown log4j jar for applications, but
the micro jar is great for constrained environments. Is this why you want it
small?
Ideally I think we should lobby the log4j folks to create the minimal log4j binary, which may entail a bit of refactoring to get it all to work cleanly (I'm a little uncomfortable with dropping in a radically different implementation of the same class name, defining a Category-esque interface would seem to be better), but I think something like the build Ceki put together is probably good enough to start with.
Has anyone brought this up on the log4j lists?
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
