JBoss.orgCommunity Documentation
How backups are performed is dependent on what persistence manager scheme you are using. Using the default one - then its a matter of backing up the repository directory (wherever you have it configured to be). Restoring it is simply a matter of copying across the repository directory.
Ideally you will either stop Guvnor application while a file backup is being done, or ensure that no one is using it.
In the case of using an external database (e.g. Oracle, MySQL), then the normal scheme can apply that you would use to backup those database (you do back them up, right?). In this case, when restoring, it is also a good idea to clear the indexes (delete the directory where the indexes are) so they are created fresh from the data (and thus guaranteed to be in sync).
It is often needed to migrate your existing repository from one persistence manager schema to another. A typical scenario for this case is if you have existing rule assets in a repository using the default file-system configuration and would like to move to storing your existing data to a RDBMS. In these cases you can use the drools-ant JackrabbitMigrationAntTask which can easily convert all your repository data from one repository configuration to another repository configuration. Example configuration for this ant task can be:
<project default="migraterepo">
<path id="migration.classpath">
<pathelement path="${classpath}" />
<fileset dir="/Users/tihomir/development/droolsjbpm/jboss-4.2.3.GA/server/default/deploy/drools-guvnor.war/WEB-INF/lib">
<include name="**/*.jar"/>
</fileset>
<filelist refid="drools-ant" />
<filelist refid="db-driver-jars" />
</path>
<filelist id="db-driver-jars" dir="/Users/tihomir/development/droolsjbpm/jboss-4.2.3.GA/server/default/lib">
<file name="mysql-connector-java-5.1.11-bin.jar" />
</filelist>
<filelist id="drools-ant" dir="lib">
<file name="drools-ant-${project.version}.jar" />
</filelist>
<taskdef name="migrate" classname="org.drools.contrib.JackrabbitMigrationAntTask"
classpathref="migration.classpath" />
<target name="migraterepo">
<record name="migration-log.txt"/>
<migrate verbose="true"
sourcedir="/Users/tihomir/development/droolsjbpm/jboss-4.2.3.GA/bin/repository/"
sourceconfig="/Users/tihomir/development/droolsjbpm/jboss-4.2.3.GA/bin/repository.xml"
targetdir="/Users/tihomir/demo-jrmigration/targetrepo/"
targetconfig="/Users/tihomir/demo-jrmigration/targetrepo/repository.xml" />
</target>
</project>
In the above scenario JackrabbitMigrationAntTask is going to migrate all repository data configured in
repository.xml defined in the sourcedir attribute, to the repository configured in
repository.xml defined in the targetconfig attribute. Note that this data migration is a full
migration, which means it migrates the entire repository which also makes it a good tool to use for backups as well.
The blog post http://blog.athico.com/2011/03/using-drools-ant-to-migrateback-up.html contains a video showing
a full example on how to use the JackrabbitMigrationAntTask for repository migration.
When building packages using the "Packages" feature you have the option to use a "selector". This selector will filter the list of rules that are built into the package.
Guvnor provides several built-in selectors which allow you to choose what assets form part of a package build according to asset's status and category.
You can use a custom selector if the built-in selector does not satisfy your requirement. To configure a
custom selector, you will need to "explode" the WAR file for Guvnor, and locate the
selectors.properties file (note you can also put your own
selectors.properties file in the system classpath if you like). In this file, you will
find details on how you can configure a custom selector. The options are to use a DRL file, or the name of
a class that you have written (and which is available on the classpath). Classes must implement the
AssetSelector interface. DRL files can also be used and there is an example one in the
selectors.properties file). Each selector you configure has a unique name in this
properties file - and this is the name that you can use when building packages.
To achieve, this, you can "explode" the deployment WAR file, and locate the
Guvnor.html file, which will look something like the following:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<!-- Note you can append #asset=UUID to the end of the URL to preload a given asset.
Also, if you appent #asset=UUID&nochrome it will only show the asset without all the GUI "chrome"
To select a locale, specify &locale=en_US at the end of the URL to pick the appropriate bundle.
-->
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
<title>JBoss Guvnor</title>
..........
</body>
</html>
Note that the above Guvnor.html file is fairly small (as most of the work is done by
the GWT - the GUI is built dynamically in the browser). The parts you can customize are the style sheet -
you can either edit the Guvnor.css (or better yet, take a copy, and change the style
to be what you need), the "shortcut icon" (its what shows in the address bar in the browser etc - also
change the "icon" link to be the same so it works in IE), and the header logo. The rest should be left as
is, to allow the GWT components to be loaded and attached to the page. This html page is loaded only once
by the browser when the user accesses Guvnor web GUI.
The best way to customize is to take a copy of the Guvnor.html file and then edit. You
can also change the URL by editing the web.xml via the normal means.
A JCR standard export/import feature is available from the Admin part of the web interface.
This will export the entire repository to an XML format as defined by the JCR standard.
In the case of import, it will clear any existing content in the database.
This is not a substitute for backup but can be useful when migrating. It is important to note that version history is not exported this way, only the current state. Hence it is still recommended that a formal backup regime be used at all times on the repository database itself.
Note that when importing repositories with many thousands of items, extra memory will be required when performing the import.