Re: commons-configurations2 doesn't strip double quotes in env variable
Hello Oliver, I tried out your solution and I can see the `properties.getArrayString()` now works. But `properties.getList()` still doesn't. I looked at the `getList()` implementation at `AbstractConfiguration` and don't see it uses the conversionHandler. I have to keep my work around by declaring a new DecoratorProperties and strips double quote in `getArrayString()` and `getList()`. Do you want me to create an JIRA issue about it? Thank you! Duc, 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.
Re: commons-configurations2 doesn't strip double quotes in env variable
>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
Re: Re: commons-configurations2 doesn't strip double quotes in env variable
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,
Re: commons-configurations2 doesn't strip double quotes in env variable
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 > - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
commons-configurations2 doesn't strip double quotes in env variable
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