> Yes. I agree that we need to have tools to debug our stuff. My problem is > that log4j is only "used" for debugging but in reality it means that that > all beans in production now must have log4j on the client side.
This is not true, log4j is used to indicate errors and warnings as well. > It is like saying: "we absolutely need Junit and Jmeter for testing our > stuff, consequently all clients applications needs to have these on their > classpath because it is easier for us.". I think this is an extreme view... but I can see how you might have derived this from the above. > If I am remember well, we never use log4j directly, right? but a wrapper > class? What I meant was: couldn't we make the wrapper not require log4j by > default. The wrapper is specific to Log4j, we could make it non-specific, but then we get into writting our own logging infrastructer, which is not something I would suggest. Why reinvent the wheel, or in this case logging. Log4j does everything we want and keeps most of the crap we don't want or need pluggable, so don't have to use it. If size is your issue... the minimal jar (log4j-core.jar) is only 76k... which I think is peanuts in the general case, and can be trimmed if required for ultraminamalists. What is your beef with log4j? I still don't understand why you want it to go. --jason _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
