Page History

...

The membership code currently has a number of dependencies on other classes within geode core. We will break these dependencies in the following waysessentially three different ways

1. Move the dependencies to a separate subproject - serialization is moving to separate subproject so that membership can depend directly on that
2. Inject dependencies at runtime - dependencies such as gemfire stats can be injected into the membership system by providing interfaces such as GMSStatsListener (see below) that geode core must provide when creating the membership system.
3. Wrap the membership APIs - some functionality is membership is tied to the rest of geode-core - for example DistributedMember is a public class that contains membership information as well as other, non membership related information. In geode-core, we can wrap the GMSMember in an appropriate class for use in the rest of geode-core.

Classes used to wrap the membership APIs or inject dependencies into membership will be put in the org.apache.geode.distributed.internal.membership.adapter package.

TODO

geode-membership API

The geode-membership subproject will provide the following API to the rest of the system. We will enforce that other parts of the system can only interact with this API.

...

geode-serialization API

The geode-membership serialization subproject will provide the following API to the rest of the system. We will enforce that other parts of the system can only interact with this API.

...