Page History

...

The ClassLoader Isolation RFC proposes that each sub-project of Geode be loaded as a separate module using JBoss Modules. This means that the classpath shown above will become much shorter as the majority of sub-projects, along with their library dependencies, are removed from it and put into modules with separate ClassLoaders. Note that this is only the case for servers and only if you opt-in; the current way of working will remain default behavior and clients will be unaffected. The new classpath when opting for the new modular behavior will look something like this:

...

Notice that only project dependencies and only those scoped to be required at runtime (runtime, runtimeOnly, compile, implementation, and api) are included in "Dependent-Modules". This is because the list is generated from the r. Other library dependencies are excluded because they will not be loaded as separate modules (though that may change in future iterations) and dependencies scoped as compileOnly or test are excluded because they are not required in production. You may also notice that the "Dependent-Modules" list contains modules that are not explicitly included in Gradle, specifically geode-tcp-server, geode-http-service, geode-common, geode-management, and geode-unsafe. These modules are included in the list because they are required by other modules that are explicitly called out in Gradle and therefore, are part of the module's runtime classpath. Generating the "Dependent-Modules" list like this results in the following relationships between modules: 

...

	For each dependency in the list:

		Get its runtime classpath

...

The reduced version of this attribute may be minimal, but it provides us all the information necessary to load and link the module.

Use Cases

Scenario 1: Sub-project A has no dependencies.

Expected Behavior: The "Dependent-Modules" attribute in modules A's manifest file is empty.

Scenario 2: Sub-project A depends on sub-project B in its build.gradle file. Sub-project B has no dependencies.

Expected Behavior: The "Dependent-Modules" attribute in modules A's manifest file contains sub-project B. Sub-project B's "Dependent-Modules" attribute is empty.

Scenario 3: Sub-project A depends on sub-project B and sub-project B depends on sub-project C. Sub-project C has no dependencies.

Expected Behavior: The "Dependent-Modules" attribute in modules A's manifest file contains sub-project B and sub-project B's "Dependent-Modules" attribute contains sub-project C. Sub-project C's "Dependent-Modules" attribute is empty.

Scenario 4: Sub-project A depends on sub-projects B and C. Sub-project B depends on sub-project C.  Sub-project C has no dependencies.

Expected Behavior: The "Dependent-Modules" attribute in modules A's manifest file contains sub-project B and sub-project B's "Dependent-Modules" attribute contains sub-project C. Sub-project C's "Dependent-Modules" attribute is empty.

Scenario 5: Sub-project A depends on sub-projects B, C, and D. Sub-project B depends on sub-project C. Sub-projects C and D have no dependencies.

Expected Behavior: The "Dependent-Modules" attribute in modules A's manifest file contains sub-project B and sub-project D. Sub-project B's "Dependent-Modules" attribute contains sub-project C. Sub-project C's and sub-project D's "Dependent-Modules" attributes are empty.

Changes and Additions to Public Interfaces

...