Hi all, I have a similar problem with my application. This is a java application (not using any application server).
I use commons-logging for logging puposes and log4j as implementation. This is working (I mean I got the log) but it is impossible to deactivate the log. All log informations go to a file named "extern.log" in the directory from which the application is launched. The log level is always DEBUG (however I mentioned ERROR in the log4.xml) and the format is the same as 2008-05-29 12:57:30,829.1 [main] DEBUG com.tsdsoftware.ouat - Environment used for the WS call: T24JBDEV I have create a commons-logging.properties file to force it to use the log4j implementation and avoid the discovery procedure but it didn't change anything to the log level. As my application is running on Windows with jdk1.6, I tried to trace all API calls to the system with Processmonitor ( http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx?PHPSESSID=d926) and I saw that the JVM accessed to the log4j.xml configuration file. But the level stays DEBUG and the output file stays extern.log. (I'm wondering where this filename comes from. I searched all source files of log4j and commons-logging but didn't find this 'default' name). Any idea ? Thanks, Pierre On Tue, Jun 3, 2008 at 3:39 AM, John B. Moore <[EMAIL PROTECTED]> wrote: > simon wrote: > > 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. >> > > What I had done is to set logging to OFF it turned of my internal code's > logging but did not touch the commons logging.. > > My conclusion was that it was not seeing the config file.. > > I then moved a copy to the /WEB-INF/classses > > I then also turn off the logging in that file.. > > ..no joy.. (and the pattern is different..) > > My pattern > > 6450 [http-8080-Processor3](BaseServiceBean.java:240) DEBUG - > BaseServiceBean - getPath: IndexPath > > the commons logging pattern > > 2008-06-02 17:58:20,901 DEBUG [org.apache.commons.digester.Digester.sax] - > endElement(,,web-app) > > ..with the date and time.. > > >> 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 searched carefully the entire classpath (JBuilder has a view that shows > you the entire classpath used on startup) and I did find A general > logging.properties file in the: > > Versions/1.5.0/Home/lib/logging.properties > > .. with the following settings.. > > #========================================== > # Default global logging level. > .level= INFO > > # default file output is in user's home directory. > java.util.logging.FileHandler.pattern = %h/java%u.log > java.util.logging.FileHandler.limit = 50000 > java.util.logging.FileHandler.count = 1 > java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter > > # Limit the message that are printed on the console to INFO and above. > java.util.logging.ConsoleHandler.level = INFO > java.util.logging.ConsoleHandler.formatter = > java.util.logging.SimpleFormatter > #============================================ > > > .. which does not seem to be in effect with commons because I'm seeing > DEBUG output.. > > The only other "properties" files I could find in that path had no mention > of logging in general or log4j in particular.. > > (I also used "SpotLight" which searched the entire hard drive and only > found what I expected to find and where I expected to find it..) > > > >> 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. >> > > Thanks I will review that... > > >> 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. >> > > I wish you where right... so far I have not been able to find such a file.. > > > >> 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. >> > > That worked.. But you are right not a good solution.. Is there something > else I could put in that file that would allow only ERROR messages to come > through..? > > Thanks for your patience and assistance.. > > John... > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
