Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Tweaking tomcat 6 logging.properties file

 
Robin Sharma
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Robin Sharma
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 18277
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic