Re: [configuration] Should we remove list splitting for attributes in XMLConfiguration?
Am 08.09.2012 18:49, schrieb Ralph Goers: No objection. I believe this was done because of the way lists are done in property files - a comma separated list of values on a single property. In XML you would just have multiple instances of the element, each with its own value. This is one of the reasons why having the "flat" configuration as the base for hierarchical configurations is bad. Yes, the idea was to be consistent with the way properties configurations work. I created https://issues.apache.org/jira/browse/CONFIGURATION-505 for handling this change. Oliver Ralph On Sep 8, 2012, at 8:11 AM, Oliver Heger wrote: Currently XMLConfiguration allows setting multiple values for an attribute node. (This is possible through the Configuration interface, but of course not supported by XML.) When saving the configuration it tries to encode the list as a comma-separated string. On reloading, such strings are split again. The implementation of this feature is pretty complex because points like escaping delimiter characters have to be taken into account. I doubt that it works in a reliable way in all possible constellations. OTOH, I don't think that this functionality provides much value to users. So, in short, I propose to remove this feature. I would change the implementation to check for attributes with multiple values when the configuration is to be saved. If such attributes are detected, an exception can be thrown. Any objections? Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] Should we remove list splitting for attributes in XMLConfiguration?
No objection. I believe this was done because of the way lists are done in property files - a comma separated list of values on a single property. In XML you would just have multiple instances of the element, each with its own value. This is one of the reasons why having the "flat" configuration as the base for hierarchical configurations is bad. Ralph On Sep 8, 2012, at 8:11 AM, Oliver Heger wrote: > Currently XMLConfiguration allows setting multiple values for an attribute > node. (This is possible through the Configuration interface, but of course > not supported by XML.) When saving the configuration it tries to encode the > list as a comma-separated string. On reloading, such strings are split again. > > The implementation of this feature is pretty complex because points like > escaping delimiter characters have to be taken into account. I doubt that it > works in a reliable way in all possible constellations. OTOH, I don't think > that this functionality provides much value to users. > > So, in short, I propose to remove this feature. I would change the > implementation to check for attributes with multiple values when the > configuration is to be saved. If such attributes are detected, an exception > can be thrown. > > Any objections? > Oliver > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[configuration] Should we remove list splitting for attributes in XMLConfiguration?
Currently XMLConfiguration allows setting multiple values for an attribute node. (This is possible through the Configuration interface, but of course not supported by XML.) When saving the configuration it tries to encode the list as a comma-separated string. On reloading, such strings are split again. The implementation of this feature is pretty complex because points like escaping delimiter characters have to be taken into account. I doubt that it works in a reliable way in all possible constellations. OTOH, I don't think that this functionality provides much value to users. So, in short, I propose to remove this feature. I would change the implementation to check for attributes with multiple values when the configuration is to be saved. If such attributes are detected, an exception can be thrown. Any objections? Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org