wood burning stoves 2.0*
The moose likes Tomcat and the fly likes Tweaking tomcat 6 logging.properties file Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Tweaking tomcat 6 logging.properties file" Watch "Tweaking tomcat 6 logging.properties file" New topic
Author

Tweaking tomcat 6 logging.properties file

Robin Sharma
Ranch Hand

Joined: Aug 24, 2005
Posts: 76
Howdy,

I'm currently using Tomcat 6.0.18. Now, I have a JPA-enabled web app deployed in it. In this app, there are typical CRUD operations on some JPA entities. Now, according to the JPA spec, whenever a getSingleResult() is performed, if no records are found, a javax.persistence.NoResultException is thrown. This is clogging up my Tomcat log files although it doesn't provide any crucial information.

So, is there a way in the conf/logging.properties file to ignore logging this particular exception?

Thanks.


DW
There is always a bug :-)
Robin Sharma
Ranch Hand

Joined: Aug 24, 2005
Posts: 76
Carrying on from the earlier post, my Tomcat 6/conf/logging.properties file has the following entries for the catalina.log file and the console:

1catalina.org.apache.juli.FileHandler.level = INFO
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.

AND

java.util.logging.ConsoleHandler.level = INFO
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

Now, is there a way to configure these to ignore any log messages belonging to a particular package, say, com.sun.xml?

Thanks.
Robin Sharma
Ranch Hand

Joined: Aug 24, 2005
Posts: 76
Never mind, i got the answer. You just need to add this at the end of the file:

# com.foo.bar -> the concerned package.
com.foo.bar.level = WARNING
Robin Sharma
Ranch Hand

Joined: Aug 24, 2005
Posts: 76
Hmm, it seems that if I launch Tomcat (v 5.5 this time), from within Eclipse, it doesn't honor the above log setting.
But, if I launch the same tomcat directly from its bin directory, it works as expected!

Could anyone provide an insight into this???

Here's the eclipse launch configuration for the above:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<launchConfiguration type="org.eclipse.jdt.launching.localJavaApplication">
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_PATHS">
<listEntry value="/apache-tomcat-5.5.23/apache-tomcat-5.5.23/bin/bootstrap.jar"/>
</listAttribute>
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_TYPES">
<listEntry value="1"/>
</listAttribute>
<booleanAttribute key="org.eclipse.jdt.debug.ui.INCLUDE_EXTERNAL_JARS" value="true"/>
<listAttribute key="org.eclipse.jdt.launching.CLASSPATH">
<listEntry value="<?xml version="1.0" encoding="UTF-8" standalone="no"?> <runtimeClasspathEntry containerPath="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/jdk1.6.0_07" path="1" type="4"/> "/>
<listEntry value="<?xml version="1.0" encoding="UTF-8" standalone="no"?> <runtimeClasspathEntry id="org.eclipse.jdt.launching.classpathentry.defaultClasspath"> <memento exportedEntriesOnly="false" project="apache-tomcat-5.5.23"/> </runtimeClasspathEntry> "/>
<listEntry value="<?xml version="1.0" encoding="UTF-8" standalone="no"?> <runtimeClasspathEntry id="org.eclipse.jdt.launching.classpathentry.variableClasspathEntry"> <memento path="3" variableString="${env_var:JAVA_HOME}\lib\tools.jar"/> </runtimeClasspathEntry> "/>
<booleanAttribute key="org.eclipse.debug.core.appendEnvironmentVariables" value="true"/>
<stringAttribute key="org.eclipse.debug.core.source_locator_id" value="org.eclipse.jdt.launching.sourceLocator.JavaSourceLookupDirector"/>
<booleanAttribute key="org.eclipse.jdt.launching.DEFAULT_CLASSPATH" value="false"/>
<stringAttribute key="org.eclipse.jdt.launching.MAIN_TYPE" value="org.apache.catalina.startup.Bootstrap"/>
<stringAttribute key="org.eclipse.jdt.launching.PROGRAM_ARGUMENTS" value="start"/>
<stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="apache-tomcat-5.5.23"/>
<stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS" value="-Xmx1024m"/>
<stringAttribute key="org.eclipse.jdt.launching.WORKING_DIRECTORY" value="${workspace_loc:apache-tomcat-5.5.23/apache-tomcat-5.5.23/bin}"/>
</launchConfiguration>


Thanks.
Robin Sharma
Ranch Hand

Joined: Aug 24, 2005
Posts: 76
Ahh, figured this out. The following system properties need to be set, so that the "logging.properties" file can be picked up.

Assuming that the tomcat is located under an Eclipse project, add the following under the "Arguments" tab of its launch configuration:

-Dcatalina.base="${project_loc}\<apache-tomcat-5.5.23_loc>"
-Dcatalina.home="${project_loc}\<apache-tomcat-5.5.23_loc>"
-Djava.util.logging.config.file="${project_loc}\<apache-tomcat-5.5.23_loc>\conf\logging.properties"
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

Cheers!
Gian Alvarez
Greenhorn

Joined: Apr 02, 2011
Posts: 1
I'm working on a project with Flex and Spring project and I need to change the level of logging on tomcat to INFO (instead of DEBUG... which is showing up in the Console). The solution posted here worked for my computer running in Windows but one of the developers is trying to run in Mac OS X and Tomcat keeps ignoring the logging.properties. This is happening on Tomcat 6.0.32 when started from Eclipse. I even tried simply changing Tomcat to use log4j, and the console logging output is still showing at DEBUG level, event though we are telling it not to. We've attempted to move the logging.properties to the workspace as well to see if it gets imported into the classpath and not ignored... still not successful.

This is becoming an issue since the reason we are changing the logging level is due to a bug in the Spring-BlazeDS Integration project. Since we can't change the logging level, our code keeps crashing.

Any support on this would be appreciated. The symptoms are the same as the ones here.

Thanks,

Gian
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15641
    
  15

Actually, I handle this situation differently. My webapps maintain a persistence layer separate from the business and UI layers, and all the JPA code is within the persistence layer. Thus, when the business layer call the persistence layer, it employs an abstract (non-JPA) method, such as "getARecord()".

inside the persistence layer's getARecord() method definition, I convert the generic request into a JPA realization of that request. Typically, something like this:



This keeps the exception outside of the Tomcat logs, and only displays it in the app logs if I have my log level set for debugging. The application code doesn't have to worry about the (unchecked) JPA-specific exception; it just tests for a null record returned.

One could alternatively check to see if the record exists BEFORE attempting to fetch it, but if that's the exceptional case, the overhead isn't worth it.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Tweaking tomcat 6 logging.properties file
 
Similar Threads
Tomcat 5.5 complains about missing log.properties
Eclipse / MyEclipse - Logging console output ?
Tomcat 5.5 logging internal process in tomcat_out.log
Starting Tomcat from Eclipse Problem
java logging : java.util.logging.config.file - accessing logging.properties in classpath