1. One Ring Install

Installing One Ring is as simple as any Java EE web app, and simpler than most. Here’s the quick way to get running with Tomcat:

These builds work with Java 7. Make sure you have Java 7 installed.
If you haven’t installed tomcat before, I recommend downloading the .zip package including tomcat below and just unpacking it to get started.
  1. Install Tomcat. see

  2. Copy the war rulesEngine-1.0.1.war file to the webapp folder as rulesEngine.war

OR download and unzip it somewhere

  1. Make sure java is in your path and run apache-tomcat-7.0.22/bin/

  2. Point your browser at http://localhost:8080/rulesEngine and you see the One Ring web interface after a short wait

  3. Edit rules in your editor and copy to the One Ring servers rules directory - by default at [server home directory]/.OneRing/rules

  4. Go to the web interface, click the rules menu link, then click the update menu item to read the new rule sets into the engine

If you are installing on Windows you need to create a c:\tmp directory (or d:\tmp). The complete set of RuleSets are copied into rules.groovy in \tmp to assist with debugging. (This will be fixed shortly

If you’ve installed it on any other server please consider writing up how you did it to share here :-)

2. Configuration

There is one configuration option: rulesDirectory, which tells One Ring where to load the rules from.

You can set the directory in a configuration file or via JNDI. To set it in JNDI make a context .xml file in the [tomcat home]/conf/Catalina/localhost/ directory called rulesEngine.xml that looks like this:

<Environment name="rulesDirectory" value="[some path to rules dir]/testRules"
    type="java.lang.String" override="false"/>

To use a configuration file you need to create a properties file called then tell the web app where to find it by setting a system environment variable called ONE_RING_CONFIG, e.g.

# export ONE_RING_CONFIG=/[path to the file]/

In the file you only need one line:[some path to rules dir]/testRules

We started out with One Ring editing the rules and storing them in the HSQL database, however this doesn’t provide a robust control over changes and the ability to test and transfer. We decided to fall back on the existing infrastructure we use every day to develop software, Version Controlled files. This lets us use our IDE or favourite editor to edit the rules, save the latest version in Git, use our Continuous Integration server to test and possibly deploy the rules, and helps with deployment. So out went the editor and we split out the rules engine so that it can be used in the IDE or and script with jUnit to test your rules.

We recommend you set-up something like this:-

  1. On your development system (rule designer) install an IDE or editor that understands groovy

  2. Associate files with the extension ".ruleset" with Groovy in your IDE

  3. Create a Groovy (or Java) project with a source directory for your rules

  4. Copy the engine.jar to the projects lib directory

  5. Create a Git (or mercurial) repository for your rules

  6. Create a unit test file like the following to test your rules

import com.nerderg.rules.RulesEngine
import com.nerderg.rules.RulesetDelegate

 * User: pmcneil
 * Date: 18/10/11
File dir = new File(".")
def nameMatch = ~/.*\.ruleset/
int count = 0
long startProcess = System.currentTimeMillis()
try {
    dir.eachFileRecurse(FileType.FILES) { File ruleFile ->
        if ( ==~ nameMatch) {
            println "Processing RuleSet File ${ruleFile.absolutePath}"
            List<RulesetDelegate> ruleSets = RulesEngine.processRules(ruleFile)
            assert ruleSets.size() > 0
            List fails = RulesEngine.testRuleset(ruleSets[0])
            fails.each {
                println "$it"
            println '---------'
            assert fails.size() == 0

            ruleSets.each { RulesetDelegate rsd ->
                rsd.runRules([testdata: 'fred.jpg'])
} catch (AssertionError e) {
    println e
println "Tested $count rules in " + (System.currentTimeMillis() - startProcess) + "ms"

Once you have written and tested your rules push them to a central repository (like Github or Bitbucket or you own private repo). From the central repository your CI server can pull down the rules and test them. You can then go to your test One Ring server, change to the rules directory and pull the changes in. Then its simply a matter of updating the rules via the web interfaces "update" menu link. You can automate all of this via Jenkins (CI server).

Once you’re happy with the tests you can push or pull the rule changes to your production server and "update" it.