On Mon, 2008-06-02 at 12:36 -0700, John B. Moore wrote: > > but libs that use commons-logging are not? > > Apparently not.. If I set it to: > > log4j.rootLogger=OFF, A1, R1 > > ..and the commons continued to output.. as in: (a brief sample) > > 2008-06-02 12:06:35,801 DEBUG [org.apache.commons.digester.Digester.sax] > - startPrefixMapping(xml,http://www.w3.org/XML/1998/namespace) > 2008-06-02 12:06:35,801 DEBUG [org.apache.commons.digester.Digester.sax] > - startPrefixMapping(xmlns,http://www.w3.org/2000/xmlns/) > 2008-06-02 12:06:35,801 DEBUG [org.apache.commons.digester.Digester.sax] > - startElement(,,extension) > 2008-06-02 12:06:35,801 DEBUG [org.apache.commons.digester.Digester] - > Pushing body text ' > > .. obviously it thinks there is a DEBUG setting.
Yes, and that is odd. This looks to me like the default formatting for log4j. In other words, it does look like log4j output rather than java.util.logging or other. But Commons-logging does not set any logging levels at all, and log4j defaults to INFO. So this suggests that *somewhere* in your classpath is another log4j configuration file which is enabling debug-level. But it is definitely not in any of the commons project jarfiles; any commons project that tried to release a jar with a logging config file in it would get voted down. > > Are the commons lib messages getting the > > ConversionPattern that you specify in your config file? If yes, then the > > right config file is being seen, and you've just not got the log4j > > command to set the threshold right. > > So I assume that there is some setting or properties file embedded > somewhere in the libs..?? Well, as noted above it won't be in any of the commons jars. Again, if you could follow my suggestion and change the output pattern a little, that would be useful. If the problem messages do not change, then that proves a different config file is in use. > > I use JBuilder and therefore the classpath is tightly controlled and is > not associated with any classpath elsewhere in my system (Mac OSX > 10.5.2) I've used some of the commons before and never had this issue > come up, hence the mystery.. Hmm. Mac OSX. Maybe you should check the JVM files themselves, just because I've never heard of anyone having this problem before and that is a less-common platform. Didn't java1.5 just get released for Mac a few weeks ago? Are you using that brand new release? > > I'm using > > commons-beanutils-bean-collections.jar > commons-beanutils-core.jar > commons-beanutils.jar > commons-codec-1.3.jar > commons-collections-3.2.1.jar > commons-httpclient-3.2.1.jar > commons-lang-2.4.jar > commons-logging-1.1.1.jar > > I've used commons-collections on occasion with out seeing this effect, > but this is the FIRST time I've use so many (due to another library that > has all of these as dependencies and yes I check that source and > directories for any logging properties files.) > > > > > > Interestingly, the default logging level for almost all logging libs is > > "INFO", and commons libs don't log much at INFO level or above. Yet you > > say that you are getting "massive" amounts of logging. So it would > > appear that somehow you have a config file in your environment that is > > forcing logging to a level lower than the default. > > To my knowledge there is only one as listed previously.. > > > > > > You could try putting a file named "commons-logging.properties" in your > > app's classpath > > I did this and it had no effect.. I assume it was because it is not > seeing my config file and is seeing something else..? It's not too surprising it had no effect. I thought that commons-logging was probably auto-detecting log4j, and so forcing it to use log4j makes no difference. There isn't a way for commons-logging to force log4j to choose a specific config file. How log4j chooses to initialise itself is log4j's business. Maybe there is a system property that will force log4j to output diagnostics about which config file it is using? That info would of course be in the log4j docs, not commons-logging. There is an option to force commons-logging to output some diagnostics which *might* be useful in your case. See the link titled "Troubleshooting guide" on the commons-logging website. I'm 95% sure that the issue is that you have another log4j config file somewhere in your classpath. And that it is NOT inside a commons jarfile. As a last resort, you could edit that commons-logging.properties file to specify NoOpLog rather than Log4JLog. That should block all messages logged via commons-logging, although all messages logged directly to log4j will not be affected. That isn't the best solution of course. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
