Claus Ibsen created CAMEL-23573:
-----------------------------------
Summary: camel-tui - Refactor CamelMonitor into per-tab classes
Key: CAMEL-23573
URL: https://issues.apache.org/jira/browse/CAMEL-23573
Project: Camel
Issue Type: Improvement
Components: camel-jbang
Reporter: Claus Ibsen
CamelMonitor.java has grown to ~6,800 lines with ~130 fields and ~124 methods
across 9 tabs. All tab state, event handling, rendering, and data logic lives
in a single class. This makes it increasingly difficult to add new features and
causes merge conflicts when working on different tabs in parallel.
Refactor by extracting each tab into its own class implementing a common
{{MonitorTab}} interface:
- {{handleEvent(KeyEvent)}} — tab-specific key handling
- {{render(Frame, Rect)}} — tab content rendering
- {{renderFooter(List<Span>)}} — footer hint rendering
Shared state ({{selectedPid}}, {{data}}, {{tabsState}}, etc.) moves to a
{{MonitorContext}} object passed to each tab.
*Extraction by complexity (recommended order):*
# Health (~100 lines, 2 fields, 2 methods) — trivial
# Consumers (~150 lines, 4 fields, 6 methods) — simple
# Circuit Breaker (~400 lines, 7 fields, 7 methods) — moderate
# Endpoints (~400 lines, 15 fields, 6 methods) — moderate
# Overview (~350 lines, 5 fields, 8 methods) — moderate
# HTTP (~500 lines, 8 fields, 10 methods) — moderate
# Log (~250 lines, 17 fields, 5 methods) — moderate
# Routes (~1,200 lines, 25+ fields, 20+ methods) — complex
# History (~900 lines, 20+ fields, 15+ methods) — complex
After refactoring, CamelMonitor.java shrinks to ~1,500 lines containing: CLI
setup, main layout rendering, global event dispatch, data refresh/parsing,
inner data classes, and tab registration.
*Benefits:*
- Each tab is a self-contained file (100-1,200 lines)
- Parallel development on different tabs without merge conflicts
- Adding new tabs = one new file + one registration line
- {{handleEvent()}} drops from 590 to ~50 lines (dispatch only)
- {{renderFooter()}} drops from 165 to ~10 lines (delegates to active tab)
*Inner data classes* (IntegrationInfo, RouteInfo, ProcessorInfo, etc.) should
also be extracted to separate files as part of this refactoring.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
