Page History

...

The initial bootstrapping implementation is "simple". The implementation will bootstrap the Apache Geode system using the current bootstrapping mechanism of `LocatorLauncher` or `ServerLauncher`.

...

registerModule(moduleMeta:ModuleMeta):boolean – Registers a module given the ModuleMeta data object. 

loadService(clazz: Class<T>): T – Load all services of type Class<T> . This functionality is equivalent to the ServiceLoader semantics currently present in Java

unloadModule(moduleName:String): boolean – Unloads the registered module

Performance Impact

Do you anticipate the proposed changes to impact performance in any way? Are there plans to measure and/or mitigate the impact?No anticipated performance impact.

Backwards Compatibility and Upgrade Path

Will the regular rolling upgrade process work with these changes?

How do the proposed changes impact backwards-compatibility? Are message or file formats changing?

Is there a need for a deprecation process to provide an upgrade path to users who will need to adjust their applications?

Prior Art

No backward compatibility impact.

No public API's being changed

Deploying of jars might have a small change in behavior. The initial implementation might require the user to deploy a fully build jar, not part-jars where the sum of the jars make up a whole. Upgrading of libraries will result in the old jar being undeployed and the new one deployed in its place.

Prior Art

An alternative to this solution is to either leave the ClassLoader model as it is currently working in Geode. Whilst the current approach has a notion of ClassLoader isolation, but the user will still be limited to the versions of the libraries that Apache Geode chooses to use.What would be the alternatives to the proposed solution? What would happen if we don’t solve the problem? Why should this proposal be preferred?

FAQ

Answers to questions you’ve commonly been asked after requesting comments for this proposal.

...