You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by To...@t-systems.com on 2017/01/11 09:04:28 UTC

[configuration] save xml list element

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>



Re: [configuration] save xml list element

Posted by Oliver Heger <ol...@oliver-heger.de>.
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 Tobias.Wolf@t-systems.com:
>> 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 Gren
>> 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 Mnchen
>> +49 89 54550 - 2479 (Tel.)
>> +49 151 168 80 221 (Mobil)
>> E-Mail: tobias.wolf@t-systems.com
>> 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 Mller, 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.
>>
>>
>> -----Ursprngliche Nachricht-----
>> Von: Oliver Heger [mailto:oliver.heger@oliver-heger.de]
>> 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 Tobias.Wolf@t-systems.com:
>>> 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: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Re: [configuration] save xml list element

Posted by Oliver Heger <ol...@oliver-heger.de>.

Am 12.01.2017 um 08:27 schrieb Tobias.Wolf@t-systems.com:
> 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 Gren
> 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 Mnchen
> +49 89 54550 - 2479 (Tel.)
> +49 151 168 80 221 (Mobil)
> E-Mail: tobias.wolf@t-systems.com
> 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 Mller, 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.
>
>
> -----Ursprngliche Nachricht-----
> Von: Oliver Heger [mailto:oliver.heger@oliver-heger.de]
> 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 Tobias.Wolf@t-systems.com:
>> 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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


AW: [configuration] save xml list element

Posted by To...@t-systems.com.
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?

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: tobias.wolf@t-systems.com 
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:oliver.heger@oliver-heger.de] 
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 Tobias.Wolf@t-systems.com:
> 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: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Re: [configuration] save xml list element

Posted by Oliver Heger <ol...@oliver-heger.de>.
Hi,

Am 11.01.2017 um 10:04 schrieb Tobias.Wolf@t-systems.com:
> 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: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org