>From looking in the code, the problem seems to be in the DefaultConversionHandler class, which is eventually invoked to convert a value into an array or a collection. In the protected extractValues() method a DisabledListDelimiterHandler is used to process the value - which of course does not handle the delimiter character. To be honest, I don't know why it was implemented that way; this could be considered a bug.
A work-around could be to implement a custom ConversionHandler that extends DefaultConversionHandler. Here you can override the extractValues() method, and if the value is a String, you can delegate to the split() method of a DefaultListDelimiterHandler. Oliver Am 28.08.19 um 13:11 schrieb Duc Tran: > 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_handling >> >> >>> Am 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, > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org