> Log4j is our logging infrastructure on the *server* side, yes. But the > client side isn't *your* infrastructure but the user's infrastructure. What > if the user wants to use another log4j version? etc. our client side code > mustn't be so intrusive.
JBoss code is running on both sides. We don't want to sacrafice logging on the client. There is alot going on there, especialy now will client interceptors. What is the big deal with the jar? We ship with a default version of the log4j.properties which only spews warnings or errors (or we should do so, and it is quite easy). And if they really want to disable all of if then they configure Log4j to use null loggers and appenders. > You know what I mean? We do not want to loose logging on the client side... and we do not want to have two seperate logging interfaces... and we deffinetly don't want to start putting System.out and printStackTrace() into that code. Your previous email sounded like you wanted to remove Log4j on the client... and I think that would be a horrible idea. Why do you want it out? You must have had a reason to send the email. Can you explain what your pain was and perhaps we can find a better solution to it (other than ditching log4j on the client). ? --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
