Thank you Oliver, I am aware of the ListDelimiterHandler. And in the code I already declare that[1] when loading properties files and having a test to prove the ListDelimiterHandler is working. but the issue with ENV variables still remains[2]. Then I had to do a tricky hack to resolve the problem but doesn't satisfy so I reached to the mailing list.
Do you have any idea? [1] https://github.com/linagora/james-project/blob/10f7aaf9a440b1bc83e88e1842b4b89fff5c96ec/server/container/guice/configuration/src/main/java/org/apache/james/utils/PropertiesProvider.java#L80 [2] https://github.com/linagora/james-project/pull/2622/commits/538be74ef1a9e713db0a68b13ac2e35fc68f1df3
Hello Duc, the problem you are facing is probably not related to double quotes, but to a change in the way delimiter characters in strings are handled. In configuration 2.x the splitting of strings at delimiter characters is disabled per default. But you can enable this feature by setting a suitable ListDelimiterHandler. This is described in the user's guide [1]. HTH Oliver [1] http://commons.apache.org/proper/commons-configuration/userguide/howto_basicfeatures.html#List_handlingAm 23.08.19 um 05:04 schrieb Duc Tran: Hello, I'm Duc, and in our projects, we just upgraded from commons-configuration 1.9 to 2.5 and we found that when passing env variables into properties file as a list like `key=${env:MY_LIST_VARIABLES}` where MY_LIST_VARIABLES is "value1, value2, value3", the new commons configuration 2.5 doesn't strip double quotes. This makes `properites.getStringArray("key")` returns an array with only element is the big string ["value1, value2, value3"] instead of what I expected and what the commons-configuration 1 does returns ["value1", "value2", "value3"] So, do you have any suggestion to keep that behavior with commons-configuration 2.5? Thank you! Duc Tran Tien,
