Skip to content

[lake] Fail fast when a lake plugin is shadowed by a jar in lib - #4203

Open
gezapeti wants to merge 5 commits into
apache:mainfrom
gezapeti:fix-1314-lake-plugin-shadowing
Open

[lake] Fail fast when a lake plugin is shadowed by a jar in lib#4203
gezapeti wants to merge 5 commits into
apache:mainfrom
gezapeti:fix-1314-lake-plugin-shadowing

Conversation

@gezapeti

@gezapeti gezapeti commented Sep 2, 2026

Copy link
Copy Markdown

Purpose

Linked issue: close #1314

A fluss-lake-<format> jar placed in <FLUSS_HOME>/lib as well as plugins/<format>/ makes the
CoordinatorServer fail with NoClassDefFoundError: org/apache/hadoop/hdfs/HdfsConfiguration from
CatalogContext.<init>.

org.apache.fluss. is parent-first, so the lib/ copy shadows the plugin and is loaded without the
dependencies bundled next to it. This rejects that setup up front instead of failing later.

Items (3) and (4) of the issue were already addressed upstream; this covers (1), (2), (5) and (6).

Brief change log

  • LakeStoragePluginSetUp resolves the plugins directory and the classpath separately. Finding the
    same format in both now fails with a message naming both locations and the jar to remove.
  • Resolution is unchanged when a plugin comes from one location only, so the Tiering Service, which
    passes a null PluginManager, is unaffected.
  • Added PluginDirectoryLayoutTest covering the deployed plugins/ layout.
  • Added a troubleshooting page and a Filesystem JARs section on the downloads page.

Detecting duplicates means the classpath SPI is now always scanned, where before it was skipped once
a plugin was found. A broken service entry there can therefore surface a ServiceConfigurationError.

Tests

  • LakeStorageTest — the duplicate is rejected and classpath-only resolution still works. Verified
    the new case fails without the production change.
  • PluginDirectoryLayoutTest — multiple plugins loaded at once, isolation between them, main
    classpath shadowing, and resolution from the plugin jar when not shadowed.
  • ./mvnw verify -pl fluss-common passes: 1798 unit and 186 integration tests. Spotless, Checkstyle
    and RAT pass.

API and Format

No public API or storage format change.

Documentation

  • New maintenance/troubleshooting-plugins.md.
  • New Filesystem JARs section on the downloads page. Two pages already linked to
    /downloads#filesystem-jars, which did not exist. It also separates the bundled fluss-fs-hdfs
    from the thin fluss-fs-hadoop, which expects Hadoop via HADOOP_CLASSPATH.
  • The filesystem overview credited fluss-fs-hadoop for the bundled HDFS plugin, which has been
    fluss-fs-hdfs since [filesystems/hdfs] Publish Bundled HDFS Artifact #1522.

Generative AI disclosure

  • Yes (please specify the tool below)

Generated-by: Claude Opus 5 (Claude Code) following the guidelines (https://github.com/apache/fluss/blob/main/AGENTS.md)

gezapeti and others added 5 commits September 2, 2026 10:22
A LakeStoragePlugin can be provided either from the plugins directory,
where it is loaded in an isolated class loader together with the
dependencies bundled next to it, or from the main classpath. Providing
it from both locations cannot work: classes under "org.apache.fluss."
are loaded parent-first, so the copy on the main classpath shadows the
one in the plugins directory while the dependencies bundled next to the
plugin stay invisible.

This is what happens when a fluss-lake-<format> jar is copied into
<FLUSS_HOME>/lib in addition to plugins/<format>/. Paimon then fails
deep inside CatalogContext with a bare "NoClassDefFoundError:
org/apache/hadoop/hdfs/HdfsConfiguration", which gives no hint about
the actual cause.

Detect the duplicate up front and fail with a message naming both
locations and the jar to remove. Resolution is unchanged when the
plugin comes from only one location, so the classpath-only setups used
by the Flink tiering job keep working.

This addresses item (1) of the analysis in apache#1314.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019dqbppMMENgRMdJxwv5GuM
Add tests for the plugin layout users actually deploy, where each plugin
lives in its own sub directory of <FLUSS_HOME>/plugins and the main
classpath is <FLUSS_HOME>/lib.

They cover several plugins installed side by side, isolation between
them, and the shadowing that breaks a deployment: a class also present
on the main classpath is loaded from there instead of from the plugin
jar whenever its package is parent-first, leaving the dependencies
bundled next to the plugin invisible. A companion test pins the healthy
case, where the same layout resolves from the plugin jar.

This addresses item (5) of the analysis in apache#1314.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019dqbppMMENgRMdJxwv5GuM
Two docs pages linked to /downloads#filesystem-jars, but the downloads
page had no such section. Add it, listing the filesystem plugin jars of
the latest release and which of them the binary release already ships,
so both links resolve.

Also spell out the choice between the two artifacts serving hdfs://:
fluss-fs-hdfs bundles Hadoop and is what the distribution ships, while
the thin fluss-fs-hadoop expects Hadoop via HADOOP_CLASSPATH. Exactly
one of them should be installed. The filesystem overview still credited
fluss-fs-hadoop for the bundled plugin, which has been fluss-fs-hdfs
since the artifacts were split.

Add a troubleshooting page explaining how plugins are loaded, why a jar
copied into <FLUSS_HOME>/lib shadows the copy under plugins/ and loses
the dependencies bundled next to it, and what each resulting error
means. Warn about it where users hit it: the filesystem overview, the
lakehouse deployment guide, and the downloads page. The lakehouse guide
also now says explicitly that its ${FLINK_HOME}/lib instructions are
about the Flink installation, not the Fluss one.

This addresses items (2) and (6) of the analysis in apache#1314.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019dqbppMMENgRMdJxwv5GuM
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

NoClassDefFoundError: org/apache/hadoop/hdfs/HdfsConfiguration when using Paimon Lakehouse

1 participant