Move gfsh code to a separate gradle sub-project

Superscript Authors: Jens Deppe, Patrick Johnson

Status: Implemented

Superseded by: N/A

Related: N/A

Problem

Geode currently has a hard dependency on Spring libraries as a result of gfsh being developed against the spring-shell library.

We would like to extract gfsh and related cli code into a separate module such that Geode can be run without gfsh as part of the core if so desired. This decoupling will have various benefits:

  • Removal of Spring dependencies from Geode core.
  • Clearer understanding of which components rely on Spring.
  • Clear separation of various generations of admin frameworks. As the newer Cluster Configuration Management functionality reaches maturity, users will be able to easily chose which functionality they wish to include.

Anti-Goals

  • It is not a goal to provide a standalone gfsh utility

Solution

We will create a new gradle subproject called geode-gfsh-cli. Ideally, all of the code in the org.apache.geode.management.internal.cli package and related unit tests, will be moved out of geode-core and into geode-gfsh-cli. geode-gfsh-cli will have a dependency on geode-core.

JMX management functionality will be unaffected except for the ability to execute gfsh commands via the MemberMXBean.processCommand method. 

Changes and Additions to Interfaces

This proposal does not add or remove any public API.

A new CacheService will be added called CommandProcessor which will enable the MemberMXBean.processCommand functionality (and thus enable gfsh capabilities).

The current mechanism to detect commands will not be changed, however the functionality will also be moved into the new module. Currently this involves scanning the classpath for classes implementing the org.springframework.shell.core.CommandMarker interface. Any user-created gfsh commands will need to depend on the new geode-gfsh-cli module.

Initial investigation has highlighted the need for at least the following changes:

  • RebalanceCommand (a gfsh command which will need to be moved into the new package) is directly coupled to RebalanceCommandOperation which is part of the new Cluster Configuration Management service. RebalanceCommand will need to be refactored to remove the coupling.
  • CliStrings contains many constants which are used in various places throughout the management code. Our initial thought is that all cli-specific strings (for example: command help strings) will remain in this class and be moved into the new module and any common strings will be moved into a class in geode-core.
  • CliUtils contains various static methods which are mostly helper methods to ease executing functions and discovering members. Our initial though is that commonly useful methods will be moved into a new ManagementUtils class and the gfsh-dependent functions will remain in CliUtils and be moved into the new package.

Performance Impact

There is no expected performance impact


Backwards Compatibility and Upgrade Path

These changes will maintain backwards compatibility with rolling upgrades.

This change will introduce a new optional geode-gfsh-cli maven artifact. Users building a classpath with maven/gradle/etc. will need to explicitly include this artifact if they wish to use gfsh commands.

Prior Art


There have been multiple proposals to make geode more modular  - Geode Modularization Proposal (work in progress), Proposal for Geode Modularization. This proposal can be considered an incremental step in that direction.


FAQ

Q: Why not create a standalone gfsh utility?

A: A proof-of-concept, using a Spring Boot jar approach, for such a thing has been created. It requires bundling all of Geode dependencies, including war files, into a single jar resulting in a ~120MB artifact. This proposal does not preclude ever doing that, but it is not a current goal.

Errata

What are minor adjustments that had to be made to the proposal since it was approved?

  • No labels