Grails: Completely disable stacktrace.log file

March 24, 2009 by Michael

Regarding my question on twitter about completely disabling the creation of stacktrace.log from a Grails application in production mode, here is my answer:

environments {
    production {
        log4j = {
            appenders {
               null name:'stacktrace'
            }
        }
    }
    development {
    }
}

Be careful: This overwrites all other log4j closures that are made outside the environment specific settings. I found no solution for that.

Background: One of my Grails 1.1 app fails to start on a Tomcat application container deployed on an Oracle Enterprise Linux server because it fails to create the stacktrace.log.

What annoyed me is that i needed to dig around in the Grails source code to find the answer to my question in “src/groovy/org/codehaus/groovy/grails/plugins/logging/Log4jConfig.groovy” within the method “createFullstackTraceAppender()”. Should be stated in the documentation (perfect place here).

Edit: If your Grails 1.1 still fails to start(*) look out for xercesImpl.jar and xml-apis.jar or similar somewhere in your Tomcat 5 directory. These are some kind of Java 1.4 compatibility layers which break things in Grails 1.1. Oracle puts these into common/endorsed. After removing them, everything went fine.

(*) Exception was:

java.lang.RuntimeException: XPathFactory#newInstance() failed to create an XPathFactory for the default object model: 
http://java.sun.com/jaxp/xpath/dom with the XPathFactoryConfigurationException: javax.xml.xpath.XPathFactoryConfigurationException: 
No XPathFctory implementation found for the object model: http://java.sun.com/jaxp/xpath/dom

7 comments

  1. Ted Naleid wrote:

    Thanks for the tip! I had a small problem with getting this to work until I put quotes around the null:

    appenders {
    ‘null’ name:’stacktrace’
    }

    After some poking around, I found the list of built in appenders in Log4jConfig.groovy:

    static final APPENDERS = [jdbc:JDBCAppender, “null”:NullAppender, console:ConsoleAppender, file:FileAppender, rollingFile:RollingFileAppender]

    Log4j configuration is a bit of an art to begin with, I’m not sure that adding a partially documented DSL on top of that does much to help things.

    I also found that the example in the grails 1.1 docs for the rollingFile appender also specifies that you should use “fileName”

    log4j = {
    appenders {
    rollingFile name:”myAppender”, maxFileSize:1024, fileName:”/tmp/logs/myApp.log”
    }
    }

    That doesn’t work, the actual property name is just “file”:

    log4j = {
    appenders {
    rollingFile name:”myAppender”, maxFileSize:1024, file:”/tmp/logs/myApp.log”
    }
    }

    Posted on April 23, 2009 at 6:25 PM | Permalink
  2. Michael wrote:

    Hi Ted,
    thanks for your comment!

    Yeah, the docs on that topic are a bit flaky… And log4j config is a kind of its own, you’re totally right.

    Cheers,
    Michael.

    Posted on April 24, 2009 at 6:54 AM | Permalink
  3. Jim Kuo wrote:

    I have searched for days for a way to turn off the stacktrace.log completely in grails 1.1+ with no avail until I found this.

    Thanks for this sharing blog. 🙂

    Posted on July 14, 2009 at 9:58 AM | Permalink
  4. Michael wrote:

    Hello Jim, you’re very welcome 🙂 Cheers,
    Michael.

    Posted on July 14, 2009 at 11:20 AM | Permalink
  5. Jean Barmash wrote:

    I was having this issue with stax (stacktrace.log) but didn’t have chance to try your suggestions yet. They just pushed an update and it started working. Yay!

    Posted on October 16, 2009 at 4:25 AM | Permalink
  6. Pavel wrote:

    Good suggestion. But it seems to me that it does not work with the Grails 1.3.4. Even the Grails official documentation absolutely useless in this regard. The Grails keep creating the stacktrace.log making a lot of paint in a deployment process. Have you managed to sort it out in the latest grails version? Thanks.

    Posted on September 30, 2010 at 10:45 PM | Permalink
  7. Anonymous Noob wrote:

    I’m having a similar problem on Stax too: http://developer.stax.net/foru.....ng-a-log4j
    but I don’t know enough to tell whether its related to this thread or not. Any ideas?

    Posted on October 12, 2010 at 6:14 AM | Permalink
Post a Comment

Your email is never published nor shared. Required fields are marked *