FYI, I have created a new Jira ticket for this issue [1].

I have some rough ideas how to fix this, but have to do some experiments.

Oliver

[1] https://issues.apache.org/jira/browse/CONFIGURATION-649

Am 12.01.2017 um 18:03 schrieb Oliver Heger:
> 
> 
> Am 12.01.2017 um 08:27 schrieb [email protected]:
>> No I`m just doing a change somewhere else, but not in that particular
>> node, but it is splitted up in separate nodes anyway. I understand
>> that you have to create an internal node for each comma separated
>> value, but why you can`t store it back as comma separated value?
>>
> This would of course be possible, but it would require somehow to track
> the original format that was used.
> 
> For PropertiesConfiguration there is a special layout class supporting
> such use cases, and there have already been similar requests for
> INIConfiguration. This issue goes in the same direction. So it would
> probably make sense to have a generic concept of configuration layout
> classes. However, I fear that it won't be trivial to come up with a
> generic design and implement it.
> 
> Nevertheless, I will have a look why the format has been changed
> although the affected property has not been touched. Maybe there is a
> bug in the code.
> 
> Oliver
> 
>> mit freundlichen Grüßen
>> Tobias Wolf
>>
>> T-Systems International GmbH
>> Systems Integration
>> Horizontal Solutions
>> Tobias Wolf
>> Software Architekt
>> Project Center ECM & ECM Strategy & Architecture Consulting
>> Dachauer Str. 651, D-80995 München
>> +49 89 54550 - 2479 (Tel.)
>> +49 151 168 80 221 (Mobil)
>> E-Mail: [email protected]
>> Internet: http://www.t-systems.com
>>
>> T-Systems International GmbH
>> Supervisory Board: Thomas Dannenfeldt (Chairman)
>> Board of Management: Reinhard Clemens (Chairman), Dr. Ferri
>> Abolhassan, Dr. Markus Müller, Georg Pepping, Hagen Rickmann, Klaus
>> Werner
>> Commercial register: Amtsgericht Frankfurt am Main HRB 55933
>> Registered office: Frankfurt am Main
>>
>>
>>
>> Notice: This transmittal and/or attachments may be privileged or
>> confidential. It is intended solely for the addressee named above. Any
>> review, dissemination, or copying is strictly prohibited. If you
>> received this transmittal in error, please notify us immediately by
>> reply and immediately delete this message and all its attachments.
>> Thank you.
>>
>>
>>
>> Big changes start small - conserve resources by not printing every
>> e-mail.
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Oliver Heger [mailto:[email protected]]
>> Gesendet: Mittwoch, 11. Januar 2017 18:04
>> An: Commons Users List
>> Betreff: Re: [configuration] save xml list element
>>
>> Hi,
>>
>> Am 11.01.2017 um 10:04 schrieb [email protected]:
>>> I`m reading a xml configuration object with a xml element containing
>>> a comma separated string:
>>>
>>> <SSLEnabledProtocols>TLSv1.1,TLSv1.2</SSLEnabledProtocols>
>>>
>>> I archive this by setting explicitly a ListDelimiterHandler
>>>
>>> this.xmlConfigBuilder = new
>>> FileBasedConfigurationBuilder<XMLConfiguration>(ExtendedXMLConfiguration.class)
>>>
>>>                                        
>>> .configure(params.xml().setFile(configFile).setExpressionEngine(new
>>> XPathExpressionEngine())
>>>
>>> .setListDelimiterHandler(new DefaultListDelimiterHandler(',')));
>>>
>>>
>>> and the reading is fine, but when I write this out I got separate xml
>>> elements for each value instead of the same comma separated value
>>> element.
>>>
>>> this.xmlConfigBuilder.save();
>>>
>>> <SSLEnabledProtocols>TLSv1.1</SSLEnabledProtocols>
>>> <SSLEnabledProtocols>TLSv1.2</SSLEnabledProtocols>
>>>
>>
>> the current implementation of XMLConfiguration internally always
>> splits strings containing the delimiter character on reading and
>> creates multiple internal node objects for the single values. This is
>> required to handle queries correctly that operate on the internal node
>> model. So when writing out such a configuration the original format is
>> lost and multiple list nodes are created.
>>
>> I would, however, assume that a change in the format only occurs if
>> there is a change in the value of the property or if the content of a
>> configuration is copied into another one. When loading an XML file the
>> configuration stores the original DOM and applies changes on it as
>> necessary. That way the original format should be kept as close as
>> possible. Are there such changes in your use case?
>>
>> Oliver
>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to