While we’ve already written a post on our scripting support in Obsidian, this post will focus specifically on our Groovy support, what we use it for and what it makes possible for you.
Given that Groovy is built for the JVM and almost any java code will work as is in a groovy script/class, supporting Groovy in Obsidian makes all sorts of things not only possible, but downright simple. Internally, Obsidian uses Groovy scripts to support a few different dynamic/configurable jobs. First, we have SpringBeanJob. This job is intended to serve one of two purposes. First, maybe you’re already using TimerTask in conjunction with Spring for scheduling. But you’re switched over to Obsidian for a more feature rich scheduling experience. You want to get up and and running quickly? Use SpringBeanJob and get your job running on Obsidian without a build/deployment cycle.
All you need to do is configure this job with the code needed to get an instance of your bean. And you indicate the name of the method(s) to call. Optionally, you can indicate the classes you need to import if you don’t wish to fully qualify your code. Here’s a sample of what the Groovy script will look like.
import com.carfey.myproject.TimerTaskBean import com.carfey.myproject.SpringContext def springBeanObject = SpringContext.get(TimerTaskBean.class) springBeanObject.fireFirstMethod() //maybe run() used to call two separate methods springBeanObject.fireSecondMethod()
That’s basically how it will work using our standard GroovyJob. Now, let’s consider the second possible use. Maybe you have a wired bean that you want to run on a schedule. To use it with TimerTask or even Quartz/Spring integration, you’d have to go through a build/deploy cycle, if only to modify Spring config. Now look back at the Groovy script above. With Obsidian, it’s the exact same approach as in our last case, with the beauty of no build or deploy. Use SpringBeanJob, get your bean handle, invoke your method(s).
We also use GroovyJob internally to provide a ReflectiveJob which is similar in nature to our SpringBeanJob, but provides support for arguments in Constructor and method calls.
But really, while our free utility jobs are easy to use and can serve some useful purposes, there’s no need to restrict yourself to these specific cases. We have created the GroovyJob so you can do pretty much anything you’d like.
Think about all the cases where dynamic access to an environment might prove useful. Maybe you need to get some data from the database to assist in troubleshooting, or you’d like to throw a quick job out to deal with some emergency condition, or just keep a failing job running by working around a failure condition. Or maybe during a testing cycle, a job is failing and you can’t figure out why. Imagine being able to take the job code, add in some extra logging lines, extract some contextual data from the db, disable the existing job and schedule a GroovyJob with your new script code. And as you get feedback, adjust and rerun. You’re probably starting to see how powerful the GroovyJob can be.
For security purposes, we don’t expose any of our script jobs in our live online demo, but download Obsidian and try them out.
The scripting jobs were available in our initial Obsidian release and these new freely provided utility jobs will be released in the upcoming release, Obsidian 1.3. Keep watching this space for a release announcement.