Archive for September, 2008

Grails stacktrace.log

Tuesday, September 30th, 2008

Grails 1.0.x started creating a stacktrace.log file in the directory where the servlet container starts. In a development environment, using grails run-app, that’s simple enough— it appears in the top level of your application. In a production environment, this becomes a problem. Your production container (e.g. Tomcat) may start someplace where it can’t create files, like /. Thus you get exceptions sent to your container’s log files like:

java.io.FileNotFoundException: stacktrace.log (Permission denied)

Also, messages are appended to stacktrace.log– so it will continue to grow if you don’t do something about it. One option is to change where your container starts, e.g. have the startup script change to its logs directory. You can also configure your grails app to change the location of the stacktrace.log file or turn it off completely.
(more…)

Grails logging

Wednesday, September 24th, 2008

To turn on display of debug log messages in Grails 1.0.2, add this to the bottom of grails-app/conf/Config.groovy:

environments {
  development {
    log4j {
      logger {
         grails."app"="debug,stdout"
         //grails="debug,stdout"    // maybe need this too
      }
    }
  }
}


Info on other versions continues below.
(more…)

Grails testing

Tuesday, September 23rd, 2008

The Grails docs talk about testing and have some example test methods but fail to describe some simple but necessary mechanics to get it going. The test methods should be in a class that extends GroovyTestCase (that word doesn’t appear at all when searching the Grails website). The class name must end with Tests since it must be in a file with a name ending in Tests.groovy under the test directory of your grails project.
(more…)

Grails .gitignore

Thursday, September 18th, 2008

I’ve started playing with git for source code revision management. Here is my first cut at a .gitignore for a Grails 1.0.3 project. Note that for previous versions you will also need (at least) a line /plugins/core


# .gitignore for Grails 1.0.3

# web application files that are overwritten by "grails upgrade"
#  cf. GRAILS_HOME/scripts/Upgrade.groovy, target( upgrade )
/web-app/WEB-INF

# IDE support files that are overwritten by "grails upgrade"
#  cf. GRAILS_HOME/scripts/CreateApp.groovy, target( createIDESupportFiles )
# to be specific, you could replace "/*" below with your project name,
#  e.g. "foobar.launch" (no slash)
.classpath
.project
.settings
/*.launch
/*.tmproj

# logs
stacktrace.log
/test/reports

# project release file
*.war


Edit: took out build.xml since grails won’t overwrite it. The eclipse dot files .classpath, .project, and .settings will also not be overwritten if they exist, but I’m still ignoring them for now.

Update: I’ve made a few additions for Grails 1.1: gitignore11

Fluxbox startup and shutdown script

Thursday, September 11th, 2008

The default Fluxbox startup file at ~/.fluxbox/startup is run by startfluxbox and has embedded comments describing how to add applications ("apps") to run before Fluxbox starts up. The startup file can be fixed to also run apps after Fluxbox starts or after Fluxbox finishes. You might run apps after Fluxbox startup to be sure that Fluxbox applies its window position/decoration settings or puts the programs in the slit. Running apps after Fluxbox finishes is useful to cleanup things that were started earlier. The example startup file given below covers both situations.
(more…)

Hello, world (again)

Thursday, September 11th, 2008

So I’m trying this blog thing again. I never really got into it because I didn’t want to post a bunch of simple chatty stuff. Then I started noticing that my web searches were finding more answers on blogs than on archived email lists. Finally, Jared Richardson convinced me during his keynote Career 2.0 at the Rich Web Experience conference. Viewing blog posts on technical issues as informal documentation makes sense to me. If I have find a solution or workaround to some problem, then it would probably help other people. Lately I’ve been trying to get my new desktop system at work up to snuff. The sysadmins barely did anything - changed the home directory and user logins to the network but didn’t even set the right time zone or setup ntp. So my first new post will be a little update to the documentation for the Fluxbox window manager that I can’t add to their wiki docs.