File persistence in Java SE

File persistence targets the Java™ SE platform. It is useful for developers who test on a single local instance of the application server.

The file persistence system relies on two configuration parameters:
  • A parameter to switch the persistence to file mode.
  • A parameter to set the working directory of file persistence.

RuleApp archives are JAR files. JAR files provide efficient packaging and access to distributed content. When a RuleApp archive is extracted, its contents is written to a root directory as a single JAR file.

Rulesets with no managed Java XOM

The root directory is named yourWorkingDir/res_data by default. You can change this name by using the setup Ant task. The default res_data directory, or your customized root directory, is structured as follows:

  • One subdirectory for each level of the canonical ruleset path.
    • RuleApp
    • RuleApp version number
    • Ruleset
    • Ruleset version number
  • Each version subdirectory contains files that store the properties of the ruleset and ruleset archive.
    • The description.txt file describes the RuleApp or ruleset. It is not mandatory.
    • The display_name.txt file contains the alternative name of the RuleApp or ruleset. It is not mandatory.
    • The creation_date.txt file contains the creation date of the RuleApp or ruleset. It is mandatory.
    • The properties.txt file contains the properties of the RuleApp and ruleset. It is mandatory only for the ruleset, as it contains at least the status of the ruleset.
    • The ruleset archives are extracted as JAR files from the RuleApp (ruleset.jar).

Rulesets with managed Java XOM

The root directory is named yourWorkingDir/res_xom by default. You can change this name by using the setup Ant task. The res_xom directory, or your customized root directory, is structured as follows:

  • Two files for each deployed resource:
    • One file for the initial content of the JAR file. This file takes the initial file name, combined with the version number computed during the deployment process. For example: myjarfile_1.0.jar
    • One file for the checksum value (SHA-1 algorithm). This file takes the name of the previous file with an additional .sha1 file name extension. For example: myjarfile_1.0.jar.sha1
  • One subdirectory for each library name. This subdirectory contains a subdirectory for each version of the library. Each version-number subdirectory contains a .ref file which contains the list of URIs in the library.

If the name of a library contains a slash ('/') character, a subfolder is added. As an example, the creation of the myLib/myTag version 1.0 results in the following subfolders: ./res_xom/myLib/myTag/1.0