CAMEL-23904: Fix CamelBeanDumpTest NPE caused by uninitialized picocli fields#24419
Conversation
…i fields The test constructed CamelBeanDump directly without picocli, so fields with @CommandLine.Option defaultValue annotations (sort, filter, scope) remained null at the Java level. The scope field caused a NullPointerException in the switch statement inside matchesScope(). Add Java field initializers matching the picocli defaults so the command works correctly when constructed outside of picocli parsing, and set the missing scope/nulls fields in the test. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 7 tested, 8 compile-only — current: 6 all testedMaveniverse Scalpel detected 15 affected modules (current approach: 6).
|
Summary
Claude Code on behalf of Guillaume Nodet
Fixes https://issues.apache.org/jira/browse/CAMEL-23904
CamelBeanDumpTest.testRequestsBeanDumpAndRendersBeansalways fails with aNullPointerException(ERROR, not assertion FAILURE) because the test constructsCamelBeanDumpdirectly without picocli command-line parsing.Root cause: Picocli's
@CommandLine.Option(defaultValue = "...")only takes effect during command-line parsing — it does NOT set the Java field's initial value. When the command is constructed directly (as in tests), String fields remainnull. Thescopefield being null causes a NPE inmatchesScope()'s switch statement, since Java'sswitchon a null String throws NPE.Fix:
= "name",= "all") to String fields inCamelBeanDumpmatching their picoclidefaultValue, so the command works correctly when constructed outside of picocli parsingscopeandnullsfields in the test to match the picocli defaultsTest plan
CamelBeanDumpTestpasses (both test methods)mvn -DskipTests install)🤖 Generated with Claude Code