> Jason, my view is extremly simple. While I do see a huuuuugggee interest in > log4j (I do really love it, be sure of that, I do) and I even do see a > huuuuuggggee interest in log4j on the client side ***while*** > developping/debugging, I see absolutely *no* interest in log4j (that I > still love) on the client side while running in production. Worst, I really > think that this is bad design/packaging.
So, disable all warnings, or probably limit the threashold to FATAL in production for clients. > You tell me "we use log4j on the client side for errors and warnings". > That's not good in production. Either we have a bad behaviour and an > exception is raised (RemoteException exists for any EJB method for > example), either we shut up. Would you appreciate, while we run your new > nice command line tool that you just implemented, that the tool output is > suddently messed up with warnings and info messages from log4j... just > because log4j had something to say? Not in production. That just means that I want to change the config, not rip out logging. > Then, I don't want to "write my own loggging infrastructure" (I repeat it: > I am super-fan of log4j). It is just that we already have and use a wrapper > for log4j. Why have we done that? For many reasons, one of them being to be > able to change the logging infrastructure we use or more simply send it to > /dev/null. It is a minimalistic change. I will take a look at it. Yes, that is good... I am not really convinced that we need the wrapper either, but we have it and it does not really hurt us. But if you want to change how the logging system behaves then change the Log4j configuration, else we start treding down the path of writting our own logging infrastructure (like to determin if we use a Log4j Logger or a Null Logger and su on). I do not feel that we really need org.jboss.logging.Logger, it is only there to give us easy access to TRACE, though you will probably find that classes that use TRACE do not use DEBUG... perhaps a few do, but for the most part they do not. I understand Scott's reasoning for doing this, but I think we could really go either way. We want to limit the loggers which are verbose so we can easily debug problems with out having to change code. This can be done wil DEBUG and a configuration to only enable DEBUG for specified loggers. Anyways, I understand your point about production, and I believe that the solution is to provide a default log4j.properties which sets the console threshold to FATAL. I belive that if and when there is something really bad going on that it would be better to bitch than to eat the error. But if a client wants to remove the console appender they certainly can, perhaps replace it with a file appender or a null appender. I think we should provide a client/log4j.properties, and then either use the `bin/classpath.sh --client` to setup the basic client classpath (which will include client/ + the files inside and/or instruct the clients to also include that directory in the classpath + the required jars. This is currently not the case, but can be made the case very easily. Then we can have a single logging config for the client, which we don't have to worry about (Log4j will handle the details for us). This means we probably should remove any existing log4j.properties from client jars. BTW, I think we should do the same for jndi.properties --jason > And remember: I love log4j. ;) =] --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
