refactor(config): extract CLIParameter and restructure Args init flow#6569
refactor(config): extract CLIParameter and restructure Args init flow#6569vividctrlalt wants to merge 10 commits intotronprotocol:developfrom
Conversation
Extract all @parameter annotations from CommonParameter into a new CLIParameter class, removing JCommander dependency from common module. Refactor Args.setParam() into a four-step flow: parse CLI, apply config, apply CLI overrides via isAssigned(), init witness. Simplify clearParam() from ~160 lines to CommonParameter.reset().
- Restructure Args.setParam into 4-step flow: parse CLI, apply config, apply CLI overrides, init witnesses - Rename setParam(Config) to applyConfigParams, setCLIParameter to applyCLIParams for clarity - Extract WitnessInitializer into 3 static methods (initFromCLIPrivateKey, initFromCFGPrivateKey, initFromKeystore) with routing in Args - Remove password/privateKey/witnessAddress/help/version/configFilePath from CommonParameter — pass as method params instead of global state - Move JDK version check from Args to FullNode entry point - Extract Configuration.getByFileName for single-param config loading
| PARAMETER.maxHttpConnectNumber = cmd.maxHttpConnectNumber; | ||
| } | ||
| if (assigned.containsKey("--storage-db-directory")) { | ||
| PARAMETER.storageDbDirectory = cmd.storageDbDirectory; |
There was a problem hiding this comment.
In applyCLIParams(), 7 storage-related parameters are written only to intermediate fields on PARAMETER, not to the PARAMETER.storage object that is actually used at runtime. The approach in applyConfigParams() is correct (writing via PARAMETER.storage.setXxx()), and applyCLIParams() should be consistent with it.
Current code in applyCLIParams:
PARAMETER.storageDbDirectory = cmd.storageDbDirectory;
Should be changed to write directly to PARAMETER.storage, consistent with applyConfigParams:
PARAMETER.storage.setDbDirectory(cmd.storageDbDirectory);
Please check the relevant parameters.
There was a problem hiding this comment.
Thanks for catching this!
The existing tests did not cover the scenario where CLI storage parameters override config file values, which is why this bug went undetected after the refactor. Two test cases have been added to cover both the CLI-overrides-config and config-defaults-without-CLI scenarios.
Fixed in c4cb0e1. Please continue reviewing, thank you!
applyCLIParams() wrote 7 storage-related values to intermediate fields on CommonParameter instead of the Storage object that is actually used at runtime. Since applyConfigParams() runs first, these CLI values were silently ignored. - Remove 7 intermediate fields from CommonParameter - Simplify applyConfigParams() to read directly from config - Fix applyCLIParams() to write directly to PARAMETER.storage - Add tests for CLI-overrides-config and config-defaults scenarios
The test failed on ARM64 because Storage.getDbEngineFromConfig() silently overrode the user's config to ROCKSDB, which is unreasonable as it hides incompatible configuration from the user. Replace the silent override with an explicit validateConfig() check in Args that fails fast with IllegalArgumentException when LevelDB is configured on ARM64. This makes the incompatibility visible instead of silently swallowed.
…erride The validateConfig() approach caused 1273 test failures on ARM64 because most tests use config files with db.engine="LEVELDB" and setParam() was throwing IllegalArgumentException before any test logic could run. Restore the original silent override in Storage.getDbEngineFromConfig() which automatically switches to ROCKSDB on ARM64. Update the testConfigStorageDefaults test to be architecture-aware.
| helpStr.append("Name:\n\tFullNode - the java-tron command line interface\n"); | ||
| String programName = Strings.isNullOrEmpty(jCommander.getProgramName()) ? "FullNode.jar" : | ||
| jCommander.getProgramName(); | ||
| helpStr.append(String.format("%nUsage: java -jar %s [options] [seedNode <seedNode> ...]%n", |
There was a problem hiding this comment.
@vividctrlalt, here I noticed that seedNode was defined as a JCommander Main Parameter (without names attribute). But in applyCLIParams(), I didn't find where it's being copied to PARAMETER.seedNodes.
I might have missed it, but I couldn't find the handling in applyCLIParams(). Should we add something like:
if (!cmd.seedNodes.isEmpty()) {
PARAMETER.seedNodes = cmd.seedNodes;
}
Apologies if I misunderstood the code flow. Please let me know if I'm missing something! Thanks for your patience.
CLI seed nodes (JCommander main parameter) were not being copied to PARAMETER.seedNode after refactoring JCommander target from PARAMETER to CLIParameter. Inline loadSeeds into applyConfigParams and add seedNodes handling in applyCLIParams so CLI values properly override config file values. Co-Authored-By: Jeremy Zhang <warku123@users.noreply.github.com>
|
@warku123 Good catch! You're right — Fixed in 9c2c55b:
Thanks for the careful review! |
3 participants
Summary
@Parameterannotations fromCommonParameterinto a newCLIParameterclass, separating CLI parsing from runtime config stateArgs.setParam()into a clear 4-step flow: parse CLI →applyConfigParams→applyCLIParams→initLocalWitnessesWitnessInitializerinto three static methods (initFromCLIPrivateKey,initFromCFGPrivateKey,initFromKeystore), with routing logic moved toArgs.initLocalWitnessespassword,privateKey,witnessAddressfromCommonParameter— sensitive credentials are now passed directly as method parameters and never stored in global stateTest plan
./gradlew :framework:test --tests "org.tron.core.config.args.*"— all parameter tests pass./gradlew :framework:test— full framework tests pass