Closed tyt-gtdg closed 2 weeks ago
@tyt-gtdg thanks for the report, but a line of code is not an actionable bug report. If you want support, please take the time to provide more details as your assumption is hiding more details that we need to investigate.
A sample application that reproduces the problem is ideal. You can attach a zip to this issue or push the code to a separate GitHub repository.
In addition, please note that Spring Framework 5.2.10.RELEASE
is no longer supported.
In light of that, please upgrade to a supported version to see if the issue still exists.
@tyt-gtdg I suppose you'd expect Spring's PropertiesPropertySource
to verify that it only contains Strings, or specifically for getPropertyNames
to ignore non-String keys? Since we just wrap a target Map/Properties instance there, we cannot reject it - but we can make getPropertyNames
leniently ignore non-String keys, just like java.util.Properties.stringPropertyNames()
does.
@tyt-gtdg thanks for the report, but a line of code is not an actionable bug report. If you want support, please take the time to provide more details as your assumption is hiding more details that we need to investigate.
A sample application that reproduces the problem is ideal. You can attach a zip to this issue or push the code to a separate GitHub repository.
static { System.getProperties().put(1,1); } public static void main(String[] args) { SpringApplication.run(SystemServerApplication.class, args); }
If you start it the way above, You will see boot failure.
at org.springframework.util.StringUtils.toStringArray(StringUtils.java:954)
Collection genericity String
@tyt-gtdg indeed, and this should be fixed in the meantime. Feel free to give a recent 6.1.7 snapshot a try...
System.getProperties().put(1,1);