Slee 1.1 Classloader demystified!

Here we go.

During our dev struggle to get v2 of Mobicents JSLEE container operational we encountered quite big problem: Class Loading scheme.
Usually class loaders are organized in classic tree structure:

• one root
• each leaf can have only one parent
• each leaf can be a root of a subtree

This has certain limitations, as proven by our JSLEE 1.0 container. Without classloader repositories/isolation there is no way for two versions of the same ra(service/Sbb/Profile) to be deployed and enabled.
Moreover it is not possible to maintain integrity of classes loaded - consider situation:

• DU1 has service using lib.jar
• DU2 also has service using lib.jar
• order of deply is: DU1,DU2
• when DU2 is deployed, classloader finds lib.jar classes and does not load them
• DU1 and DU2 services kick in, instances of lib.jar classes are created (from DU1 definition)
• now DU1 is undeployed
• error on class casting - vague information: can not cast XXYX.class to XXYX.class

Now regarding Mobicents JSLEE v1. JSLEE Specs did not define any way of providing dependency classes. To resolve this problem we altered a bit DU structure, each DU jar could have "library" dir with dependencies for particular DU. This proved to be enough to solve dependencies, however all above problems still apply.
Obviously JSR240 specs lead got a notion that specs lack something valuable here and in 1.1 it has been improved.
In 1.1 container "library" component has been introduced. It is not a functional component/jar - not in terms of slee, like SbbComponent or ProfileCompoment. Its only purpose is to provide standarised and versioned way to provide classes to Slee components. So no more DU/library!!
Now about classloaders. In SLEE v1.1 model has changed as well. Its a bit tricky. Consider classic model - tree, where each classloader with one parent. This is not sufficient for SLEE v1.1. New model allows multiple parent for each leaf to reflect components relation.

Classloaders are defined per component - that is not jar, but actual identifiable component(which has ComopnentID). Component class loader loads all classes from component jar "and" all classes from referenced components.
Consider case of jar file which contains definition of Sbb1, Sbb2 and Sbb3 - all sbb classes are in jar.

So:

• three classloaders - Sbb1,Sbb2, Sbb3 - each "has" classes from jar
• SbbX classloader has access to all referenced component classloaders

Actually component class loaders deffer queries to jar domain classloader to avoid that vague ClassCastException described above. Through references in xml descriptor classlaoder association is built(multiple parents - Sbb components usually references events, ras, other sbbs, profiles, etc...) - this is place where multiple parents are introduced. See diagram below, this should give a hint: