Classloading - Xyna-Factory/xyna GitHub Wiki
Classloading is the means by which the Java Virtual Machine (JVM) creates new class objects and how it is possible to switch class objects in a running Java application. It also enables the possibility of having loaded multiple classes with the same fully qualified name in parallel (used by different independent Runtime Contexts). It is important to understand the Classloading policies in Xyna Factory to be able to fully understand how Shared Libraries or other plugins (Service Groups, Triggers, Filters, etc.) interact.
All classes that may be switched during runtime have their own classloaders:
- Trigger
- Filter
- XMOM Objects, such as Data Types, especially Coded Services
- Shared Libraries
- Persistence Layer
- Types of Data Models
- etc.
The classloading context contains:
- Global class path (all JAR files in
$XYNA_HOME/server/liband$XYNA_HOME/server/userlib) - Class files in the implementation JAR files
- Shared Libraries used by the object
- If Filter or Coded Service: All XMOM Objects
- If Filter: Context of corresponding Trigger
- Classloading context inherited by type inheritance
When a class has changed (by reloading it with a new classloader), all other objects that know this class (dependent objects) have to be reloaded by a new classloader as well. If that would not happen, the dependent objects will get LinkageErrors, because the classes don't know the properties of this class as it is currently defined. For example a method that is called by the dependent object may not exist any more.
Because of the class reloading, Coded Services can implement the methods onDeployment and onUndeployment. They can be used to initialize or clean up state that was valid only for one state of a classloader. These are called by the infrastructure whenever the classloader has to be switched (typically triggered by a deployment of this or a related object).