I’ve put together a screen cast showing how to configure Tomcat and VisualVM for a secure JMX connection using self-signed certificates and a password. You can download it as a Quicktime video here:

Managing Tomcat with JMX (43.4MB, 1024×768)

This is a slightly cleaned-up version of some video in a talk I gave at SpringOne 2GX last week entitled Grails in the Real World. The talk was a summary of my experiences as a Grails developer and trainer, including a few tools and techniques I think are helpful when using Grails successfully in the wild. I talked a lot about Liquibase, some common GORM pitfalls, how to approach training and advocacy of Grails, and of course, how to use JMX.

Even though JMX is a very mature technology, getting this kind of thing to work is a perennial pain for users of any application container and web framework. I hope this quick video helps you out. Let me know how I could have improved it!

I’ve been using Gradle for my Groovy builds recently. I consider myself a Build Diletteante, having done complex builds in days of yore using Ant, and having done the bulk of my recent builds in Grails, which is to say I haven’t really done a lot of complex builds in a while. Anyway, from my vantage point, Gradle seems to do everything right, and I’m excited to be seeing its rise to prominence.

It has just about everything it needs, but what it lacks is a convenient and well-documented means of executing a Groovy script inside a task with the project’s classes and compile-time JARs on the script’s CLASSPATH. Because, I mean, who doesn’t want that? Well, I do; I frequently find myself developing a small collection of classes which I want to exercise both through unit tests and through an integration-test-like script. I don’t want to push all of the script code into the build file, but I want the script to run as a first-class citizen of the build. “groovy -cp build/classes/main:foo.jar:monkey.jar… script.groovy” is only tolerable for so long.

And we need tolerate it no longer! Herewith my solution, entirely in the build file:

The classname passed to the Java task is simply the script’s package followed by the name of the script. In this example, we would want a file called script.groovy in the Groovy source tree that looks like this:

I have to believe this is a slightly unconventional need of mine, but I keep bumping into it, so I’m pretty happy to have solved it. Hope this helps! Thanks go to Adam Murdoch on the Gradle User list for pointing me to sourceSets.main.runtimeClasspath, which helped me find classesDir and a whole lot more.

This past Tuesday, I gave an Ignite-style talk at DOSUG. I recorded the audio and combined it with the slides (with their prescribed timing) and uploaded the finished product to Vimeo. (It turns out 20 slides of 15-second auto advance works out to be more like 5:06 than 5:00, but who’s counting?)

The talk is an exploration of the hero culture in software development, with lessons drawn from the epic poem Beowulf. Beowulf is, the consensus of medieval scholars notwithstanding, a parable about software teams gone bad. We ignore its lessons at our personal and collective peril.

from on .