Loading RuleApps in the memory persistence implicitly

When no ruleset in the memory persistence matches the ruleset path that the XU tries to execute, a heuristic, which is composed of several default strategies, is triggered and tries to load a corresponding RuleApp from the application classloader.

There are four default strategies. The first strategy is triggered when no ruleset is found in the memory persistence that matches the ruleset path that the XU tries to execute. If it does not work, the next strategy is triggered automatically.
Default strategies workflow

First strategy

The first strategy looks up a RuleApp archive that is packaged as a resource in your Java™ SE application.

For example, your application is executing a ruleset in the myRuleApp/myRuleset ruleset path with the rule sessions API. This strategy automatically looks for the myRuleApp.jar resource file in the application classloader. See the following Maven project structure:
Example of the first strategy
If one of the following cases happens and the first strategy does not work, the second strategy is triggered:
  • No such RuleApp is found in the classloader.
  • The RuleApp is loaded, but no ruleset is found that matches the execution ruleset path in the memory persistence.

Second strategy

The second strategy looks up a RuleApp as a resource in your Java SE application. Instead of looking for a RuleApp archive (.jar) as a resource, it looks up the first available RuleApp in a decompressed folder structure.

This strategy can be used in the following two use cases:

[Case 1] The RuleApp archive is not packaged as a resource, but it is available in the runtime class path of your application.

For example, you have a dependency to your RuleApp archive artifact in the configuration file pom.xml in your application Maven project:
<!-- DIRECT DEPENDENCY TO DECISION SERVICE (RULEAPP ARCHIVE) -->
<dependencies>
    ...
    <dependency>
        <groupId>my.org.group.id</groupId>
        <artifactId>myRuleApp</artifactId>
        <version>1.0</version>
    </dependency>
</dependencies>
In Eclipse, it corresponds to the following application class path:
Example of the fourth strategy

[Case 2] The RuleApp is packaged as a resource in your application, but as a decompressed folder.

For example, see the following Maven project structure:
Example of the second strategy
If one of the following cases happens and the second strategy does not work, the third strategy is triggered:
  • No such RuleApp is found.
  • The RuleApp is loaded, but no ruleset is found that matches the execution ruleset path in the memory persistence.

Third strategy

In the third strategy, RuleApps are also available in the runtime class path of your application. Like the second strategy, it looks up a RuleApp in a decompressed folder structure.

While the second strategy checks only the first RuleApp it finds in the resources of your application, this strategy can check multiple RuleApps.

For example, your application tries to execute a ruleset in the myRuleApp/myRuleset ruleset path. However, no ruleset is found that matches this ruleset path in the memory persistence. In that case, this strategy looks up the RuleApp archive in /myRuleApp/META-INF/archive.xml file in the application classloader, and tries to load the RuleApp from the classloader /myRuleApp/myRuleApp/ resource folder hierarchy.
Example of the third strategy
If one of the following cases happens and the third strategy does not work, the forth and last strategy is triggered:
  • No such RuleApp is found.
  • The RuleApp is loaded, but no ruleset is found that matches the execution ruleset path in the memory persistence.

Fourth strategy

The fourth strategy tries to load the application class path runtime JAR entries as a RuleApp archive. Each class path JAR entry is tried only once.

For example, see the following list of class path JAR entries in Eclipse:
Example of the fourth strategy
In this example, this strategy tries to load each of the following JAR files as a RuleApp (not necessarily in this order):
  • connector-api-1.5-IBM.jar
  • junit-412-sources.jar
  • harmcrest-core-1.3-sources.jar
  • jrules-res-9.6.0-execution.jar
  • jrules-engine-9.6.0.jar
  • myXom-10.jar
  • myRuleApp-10.jar
If one of the following cases happens and the fourth strategy does not work, the execution fails:
  • No such RuleApp is found as a class path JAR entry.
  • The application class path JAR entry is loaded, but no ruleset is found that matches the execution ruleset path in the memory persistence.