Selective Suppression of Log Messages

Those of you who regularly read this blog will probably have noticed that I have a strange predilection for logging related topics, so why break this habit I ask? 

Anyway here's an issue which came up recently that I thought was a good one to mention in a brief post.  The scenario really applies to production applications where you are seeing entries in the log files which are harmless, you know why they are there and are happy to ignore them, but at the same time you either can't or don't want to risk changing the deployed code to "fix" it to remove the underlying cause. (I'm not judging here). The good news is that the logging mechanism provides a filtering capability which can be applied to a particular logger to selectively "let a message through" or suppress it. This is the technique outlined below.

First Create Your Filter 

You create a logging filter by implementing the java.util.logging.Filter interface. This is a very simple interface and basically defines one method isLoggable() which simply has to return a boolean value. A return of false will suppress that particular log message and not pass it onto the handler.

The method is passed the log record of type java.util.logging.LogRecord which provides you with access to everything you need to decide if you want to let this log message pass through or not, for example  getLoggerName(), getMessage() and so on.

So an example implementation might look like this if we wanted to filter out all the log messages that start with the string "DEBUG" when the logging level is not set to FINEST:

 public class MyLoggingFilter implements Filter {
    public boolean isLoggable(LogRecord record) {
        if (  !record.getLevel().equals(Level.FINEST) 
            && record.getMessage().startsWith("DEBUG")){
         return false;   
        return true;


This code needs to be put into a JAR and added to your WebLogic classpath.  It's too late to load it as part of an application, so instead you need to put the JAR file into the WebLogic classpath using a mechanism such as the PRE_CLASSPATH setting in your domain setDomainEnv script. Then restart WLS of course.


The final piece if to actually assign the filter.  The simplest way to do this is to add the filter attribute to the logger definition in the logging.xml file. For example, you may choose to define a logger for a specific class that is raising these messages and only apply the filter in that case. 

<logger name="some.vendor.adf.ClassICantChange"

You can also apply the filter using WLST if you want a more script-y solution.


Hi Duncan

Hope all is well with you and family stateside. Like this blog post. I suppose the twist side to suppressing log messages is if a log is passed to a consultant or a support engineer to review and the administrator or developer fails to mention the suppression. From a support engineer's perspective I like the idea of using the PRE_CLASSPATH as the use of suppression would be easier to spot than if it was buried in an application jar. Am thinking also that the suppression can also be temporarily lifted if this method is used.

Posted by Dan Mortimer on December 07, 2012 at 04:51 PM GMT #

Dan, you can of course remove the filter from the running app with WLST as well (in theory - I've not tried that yet)

Posted by Duncan on December 07, 2012 at 04:56 PM GMT #

Hi, Dunkan.
If I need to copy application log messages to a database table, can I use filter for it? Say, if I only need to log messages from classes that are configured in logging.xml.

Posted by Fedir Zymarev on December 12, 2012 at 09:23 AM GMT #

No, you should be using a logging handler for that not a filter

Posted by Duncan on December 12, 2012 at 10:52 AM GMT #

Thank you for the blog post Duncan.

Just wanted to post a reference to an example implementing what the blog is about,
in the ADFEMG JIRA issue ADFEMG-191, "12c error : HttpSessionScopeAdapter : Request is in an invalid state"

Jan Vervecken

Posted by guest on December 10, 2013 at 11:11 AM GMT #

Post a Comment:
  • HTML Syntax: NOT allowed

Hawaii, Yes! Duncan has been around Oracle technology way too long but occasionally has interesting things to say. He works in the Development Tools Division at Oracle, but you guessed that right? In his spare time he contributes to the Hudson CI Server Project at Eclipse
Follow DuncanMills on Twitter

Note that comments on this blog are moderated so (1) There may be a delay before it gets published (2) I reserve the right to ignore silly questions and comment spam is not tolerated - it gets deleted so don't even bother, we all have better things to do with our lives.
However, don't be put off, I want to hear what you have to say!


« June 2016