Filter ConfigDataLocation imports null elements.
It could be NPE at ConfigDataEnvironment#getMandatoryImports
Comment From: wilkinsona
Thanks for the pull request. I'm not sure that we should silently filter out null entries. If an import has been configured with a trailing comma, as shown in the tests (spring.config.import: testimport.yml,), this is likely to be due to a typo. I think the NPE is preferable to silently hiding the mistake, but something that fails and describes the cause of the null entry (if we can figure that out) would be preferable to a NPE. Let's see what the rest of the team thinks.
Comment From: mhyeon-lee
@wilkinsona Thank you for your review. If Exception is a better choice than filtering, I will change it to throw NPE with a message explaining the reason.
Comment From: prasoonanand
The issue is with delimitedStringToCollectionConverter.getElements(source, delimiter)
which in turn calls StringUtils.delimitedListToStringArray(source, Delimiter.NONE.equals(delimiter) ? null : delimiter)...
For an example string "a,b," the method of StringUtils of Spring returns ["a", "b", ""]...
whereas Java String class String.split(delimiter) returns ["a", "b"]...
Don't know if we call this a issue at spring boot end...
Comment From: scottfrederick
@mhyeon-lee We received issue #26342, which I fixed in https://github.com/spring-projects/spring-boot/commit/dbee0cf9f1c8ed07bda4609fa7552ffdfcef7e1d. The commit removes the empty spring.config.import entries in a different place than the changes in this PR, which results in empty entries also being removed for spring.config.location when a comma-separated list is provided for that property.
Since the existing commit has broader coverage, I'll close this PR. I apologize for not realizing that we had an open PR that addressed the same problem and giving you a chance to modify your contribution. Thanks very much for noticing the issue first and for submitting the PR, and we look forward to more contributions in the future.