GemFire: Identifying and Excluding Server-Side Transitive Dependencies for Clients

Products

• VMware Tanzu Gemfire

Issue/Introduction

When building a GemFire client application (e.g., GemFire 10.0.x or 10.1.x) using Maven or Gradle, several transitive dependencies are pulled in that appear to be server-side only. These include:

• jgroups
• rmiio
• netty-handler / netty-codec (in non-SSL environments)

Users may wish to exclude these to reduce the application's deployment footprint or to avoid security scanning flags on unused components.

Environment

GemFire

Cause

In Tanzu GemFire versions prior to the full decoupling of the client and server modules, the gemfire-core dependency is used for both roles. Consequently, the client transitively inherits libraries required for server-only features such as peer-to-peer membership, WAN replication, and JMX management.

Resolution

1. Reference the Client Dependency Template

Starting with GemFire 10.1, a reference ZIP file is included in the distribution that lists only the JARs necessary for a client. You can use this as a "whitelist" for your project.

• Location: $GEMFIRE_HOME/tools/Modules/gemfire-session-management/gemfire-client-dependencies-<version>.zip

2. Common Exclusions

The following dependencies are typically safe to exclude in a client-only environment:

• JGroups: Used for server/locator membership and WAN gateway communication. It is not used by standard Java clients connecting to a cluster pool.
  
  
• RMIIO: Used primarily by the JMX Manager (server-side) for management and monitoring tasks.
  
  
• Netty (Conditional): If your client application does not use SSL/TLS, Netty handlers may be excluded. However, if SSL is enabled, Netty is required for the secure transport layer.