Grails 1.1 has changed logging setup completely, introducing a
new DSL closure.
For the most part it's cool, but the syntax looks the same sometimes for both
log level and appender assignments. I've updated my previous posts on
debug logging
and
stacktrace.log.
For the record, included below is the complete log4j closure I'm now using for
a new Grails 1.1 project (or
download
it). Append this to the default Config.groovy file.
Sigh. The ubiquitous utility less does a really bad and hard to understand
thing. For some time now, it behaves not just as a reader but also a writer:
it writes a history file (specified by the environment variable LESSHISTFILE
which is $HOME/.lesshst by default). If you want less to be writing
things, fine, but don't force it on me! This has caused some annoying
problems that have been really hard to finally trace back to less.
I recently refactored another developer's code to clean up some massive amounts of database pings to retrieve the current user object. The main problem was in the use of the logged_in_user or current_user idiom in Rails. Several places give good examples but leave out the details that were bugging my project.
(read more)The default generated error.gsp view in Grails displays the stacktrace for any exceptions that occur. That's nice for debugging in a development environment but it is a security issue for production as it is information leakage. We can easily turn this off when not in development, and do something useful like redirect to the application homepage.
(read more)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:
To turn on display of debug log messages in Grails 1.0.2, add this to the
bottom of grails-app/conf/Config.groovy:
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.
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.
(read more)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.