The introduction of dynamic rule submission and deletion raises the need for some form of rule lifecycle management, allowing the rule programmer to initiate activities when rules are loaded and curtail them when rules are unloaded. The proposed mechanism to support this option is to identify specific callback methods attached to helper classes and to invoke them at suitable points when rules which reference that helper are loaded or unloaded.

There are four specific lifecycle events and associated helper callbacks: activate, install, uninstall and deactivate. Lifecycle events only occur when a rule r(H) which employs helper class H is inserted or removed from the set R(H) of active rules employing H as their helper.

An activate event occurs when insertion of a rule r(H) causes R(H) to transition from from empty to non-empty. If the helper class H implements static public method activated() then it is called when this event occurs.

A deactivate event occurs when deletion of a rule r(H) causes R(H) to transition from from non- empty to empty. If the helper class H implements static public method deactivated() then it is called when this event occurs.

An install event occurs when a rule r(H) is added to set R(H). If the helper class H implements static public method installed(Rule) then it is called when this event occurs with the rule object supplied as parameter. Alternatively, if the helper class H implements static public method installed(String) then it is called when this event occurs with the rule name supplied as parameter (only the first method will be called if both are defined).

If the rule insertion also triggers an activate event then the activate callback precedes the install callback.

An uninstall event occurs when a rule r(H) is removed from set R(H). If the helper class H implements static public method uninstalled(Rule) then it is called when this event occurs with the rule object supplied as parameter. Alternatively, if the helper class H implements static public method installed(String) then it is called when this event occurs with the rule name supplied as parameter (only the first method will be called if both are defined.

If the rule deletion also triggers a deactivate event then the deactivate callback succeeds the install callback.

Note that the helper class is synchronized on around calls to helper lifecycle methods in order to avoid races between installs and uninstalls. It is up to the implementor of the lifecycle methods to avoid any potential deadlock this may cause.

Ok, here are some wrinkles to consider:

Insertion and deletion of rules r(H) from the active rule set R(H) should be driven by rule loading and unloading. However, it is not quite so simple as adding the rule to the set when it is read from a file/listener socket and removing when an unload request comes in via the listener.

A rule is only deemed to be active once it has been loaded, injected into a trigger method, triggered and type-checked/compiled i.e. at the point when it is about to be executed for the first time. It is only at this point that the rule (and indeed its helper class) is known to be valid. For example, rules which are loaded but are found to have parse or type errors do not become active. Valid rules which never get triggered (or get removed before a trigger event occurs) also do not become active. That's actually quite reasonable since the rule has no real effect unless a trigger call ends up being able to run it. In particular if a rule needs the helper to be initialised in order for it to work and uninitialised once it is no longer capable of runing then there should be no harm in not iniitalising/de-initialising it if the rule never runs.