Skip to content

feat(cli): direct-mode CLI — java -jar kview.jar --cli talks to the broker without a server - #9

Merged
ritikbansod merged 1 commit into
mainfrom
feat/direct-cli
Sep 28, 2026
Merged

ritikbansod merged 1 commit into
mainfrom
feat/direct-cli

Conversation

@ritikbansod

Copy link
Copy Markdown
Owner

User-facing feature: an independent CLI mode — kview topics --bootstrap-server localhost:9092 like every other Kafka CLI, with no running Kview server. Until now the CLI was a thin REST client that required the server; this adds the direct path. Stacked on #8 — merge #1 → … → #8 → this.

How it works

KafkaWrapperApplication.main detects --cli and routes to CliMain, which boots a headless application context (WebApplicationType.NONE — no Tomcat, no port) and registers the connection as an ad-hoc in-memory cluster profile. That single hook makes every existing service work unchanged against the broker:

  • browse / search come out schema-registry decoded (Avro, JSON Schema, Protobuf — same code paths as the UI); --schema-registry URL attaches a volatile registry (never persisted).
  • produce / replay / lag / groups / topics / topic / overview reuse the exact server implementations.
  • Security flags (--security-protocol, --sasl-*, --keystore-*, --truststore-*, --oauth-*, --no-hostname-verification) map onto the existing SecuritySettings, so SASL_SSL/SCRAM/mTLS/OAuth work the way the server does them.
  • --json on every command; --data-dir isolates state; exit codes 0/1/2 (success/failure/usage).

Shipped kview (sh) and kview.cmd wrapper scripts pick up the jar next to them, so after a release download or mvn package it's just kview topics --bootstrap-server ....

Only two touch points on existing code, both in-memory-only: KafkaClusterManager.registerAdHoc and RegistrySettingsStore.attachVolatile.

Verification

  • CliModeTest boots its own headless context against an embedded broker and drives produce → browse → topics end to end (JSON output asserted), plus the exit-code contract (help=0, unknown command=2, missing required flag=1).
  • Packaged-jar smoke: java -jar kview.jar --cli help prints usage and exits 0.
  • Full suite: 66/66 green.
  • Not covered: interactive auth flows (OAuth token refresh is the same handler the server uses); a live SASL_SSL cluster run.

…roker without a server

The user-facing ask: 'like other CLIs work — kview topics against the broker'.
The thin REST client needed a running Kview server; direct mode does not.

- --cli detection in KafkaWrapperApplication.main routes to CliMain, which
  boots a headless (WebApplicationType.NONE) application context — no Tomcat,
  no port — and registers the connection as an ad-hoc in-memory cluster
  profile, so every existing service works unchanged against the broker.
- Commands: overview, topics, topic, browse (schema-registry decoded),
  groups, lag, produce, search (background search service), replay — each
  with --json output. Security flags cover SASL/mTLS/OAuth via
  SecuritySettings; --schema-registry URL attaches a volatile registry for
  payload decoding; --data-dir isolates state.
- shipped kview / kview.cmd wrapper scripts that pick up the jar next to
  them, so 'kview topics --bootstrap-server ...' works after a release
  download or mvn package.
- KafkaClusterManager.registerAdHoc + RegistrySettingsStore.attachVolatile
  are the only touch points on existing code (in-memory only, nothing
  persisted).
- tests: CliModeTest boots its own headless context against an embedded
  broker and drives produce/browse/topics end to end plus exit-code
  contract. Full suite 66/66.
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.

1 participant