Some older Config-enum-derived entries where the ConfigKey type is String even though every call site immediately parses it as a number, e.g. BaremetalIpmiRetryTimes (declared ConfigKey, parsed via Integer.parseInt(...) everywhere it's read). That's latent type-modeling debt worth its own cleanup pass across the codebase, not just the handful of call sites this migration touched.
Change those ConfigKey items
some occurances in claude’s words:
Genuine type mismatches — the ConfigKey's declared type doesn't match how the value is actually used, so a bare .value() swap either won't compile or silently changes behavior:
- StorageManagerImpl.java — 4 sites (VmDiskThrottlingBytesReadRate, VmDiskThrottlingBytesWriteRate, VmDiskThrottlingIopsReadRate, VmDiskThrottlingIopsWriteRate): each is ConfigKey but read into a Long local via Long.parseLong(…).
- VmwareManagerImpl.java — VmwareVcenterSessionTimeout: ConfigKey but stored into an int field (_vCenterSessionTimeout), multiplied by 1000.
- NetscalerElement.java — NCCCmdTimeOut: ConfigKey but currently forced through NumbersUtil.parseInt(...) then Long.toString(...) — an existing silent-truncation bug that .value() would actually fix, but that's a behavior change needing sign-off, not a silent slip-in.
Some older Config-enum-derived entries where the ConfigKey type is String even though every call site immediately parses it as a number, e.g. BaremetalIpmiRetryTimes (declared ConfigKey, parsed via Integer.parseInt(...) everywhere it's read). That's latent type-modeling debt worth its own cleanup pass across the codebase, not just the handful of call sites this migration touched.
Change those ConfigKey items
some occurances in claude’s words: