Execution unit (XU) and Java class loading
The execution unit handles various class loaders in relationship with the XU client.
- XU class loader in Jakarta EE environments
- When the XU is deployed as a global Jakarta EE resource adapter, its classes are by default available to all deployed Jakarta EE applications. Because the XU embeds multiple dependencies, Jakarta EE applications might be incompatible if they use different versions of the same libraries. Depending on the capability of the Jakarta EE application server, you might have to isolate the class loader of the XU or to change the class look-up strategy of the Jakarta EE application to parent last. The XU client can communicate with the XU without any class loader relationship but in this case, performance decreases. Preferably, make the Jakarta EE application use the classes from the XU class loader.
- Rule engine class loader
Unlike most Jakarta EE resource adapters, the XU does not connect to a server or a process.
The decision engine (DE) is directly embedded in the XU Jakarta EE packaging.
The classes of the rule engine itself are in the XU class loader, which is the class loader of the Jakarta EE resource adapter.
- XOM class loader
- The rule engine is able to execute rules on objects that are in
a different class loader from the engine itself. That different class
loader is called the XOM class loader. To match the rules correctly,
the classes of the objects must be in the XOM class loader (or the
parent class loader). The XOM class loader is passed by the XU client.
The rule session sets the XOM class loader to the context class loader
of the caller thread (
Thread.currentThread.getContextClassLoadermethod). The XU can execute different rulesets at the same time and can execute the same ruleset with a different XOM class loader. In this case, several instances of the ruleset are used, one for each XOM class loader.Even if the XU is deployed as a global Jakarta EE resource adapter, the following mechanism is true: If application A executes ruleset B, it uses a ruleset instance that is bound to the XOM class loader of A. If an application C® executes the same ruleset B, it uses a different ruleset instance that is bound to the XOM class loader of C. In any case, application C cannot use a ruleset that is bound to the A class loader. If you undeploy A, the ruleset that is dedicated to application C is not affected. Generally, if you redeploy a Jakarta EE application, its class loader is changed. The consequence is twofold:- If you change XOM classes, the change is automatically taken into account.
- Even if the XOM classes have not changed, the ruleset is parsed and a new ruleset instance is created.
Note: The XU is not aware whether the ruleset is really using XOM classes, so this behavior is valid even if no XOM classes exist. - Managed XOM class loader
- You can deploy XOM classes to the Rule Execution Server persistence
layer. In this case, the XU triggers the following effects:
- Creates a class loader and pass it to the rule engine.
- Injects the XOM classes in this class loader.
- Sets the parent of this class loader to the class loader passed by the XU client.
- Uses the default Java™ class look-up strategy (parent first).
The following consequences ensue:- If a XOM class is not in the class loader that is passed by the XU client, the XOM class of the managed XOM that is deployed to the Rule Execution Server persistence layer is used.
- If a XOM class is in the class loader that is passed by the XU client, that XOM class is used.