from:"Emmanuel Bourg"


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498512
 ] 

Emmanuel Bourg commented on CONFIGURATION-273:
--

Just curious, what is the use case for this feature ? The one I see is to save 
a PropertiesConfiguration as a standard Properties file to be read by another 
application not using Commons Configuration.

This can be achieved with ConfigurationConverter.getProperties(config), it 
performs the interpolation of the variables :

PropertiesConfiguration config = new 
PropertiesConfiguration(conf.properties);
Properties props = ConfigurationConverter.getProperties(config);
FileOutputStream out = new FileOutputStream(conf2.properties)
props.save(out, null);
out.close();



 Saving with interpolation
 -

 Key: CONFIGURATION-273
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-273
 Project: Commons Configuration
  Issue Type: New Feature
Affects Versions: 1.4
Reporter: Daniel Adrian

 It will be very nice if you'll add the ability to save a configuration file 
 with the interpolation data.
 so if my config file is :
 my_home=127.0.0.1
 my_place=Is ${my_home}
 when I save the configuration (let's say with save(true)) it will look like
 my_home=127.0.0.1
 my_place=Is 127.0.0.1
 Thank you!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (CONFIGURATION-269) PropertiesConfiguration.save() generates superfluous escaping character when delimiter parsing is disabled


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg resolved CONFIGURATION-269.
--

Resolution: Fixed

Thank you for the test Oliver, I integrated it. I added a ConfigurationAssert 
class to check if two configurations are similar, that may be useful elsewhere.

 PropertiesConfiguration.save() generates superfluous escaping character when 
 delimiter parsing is disabled
 --

 Key: CONFIGURATION-269
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-269
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Oliver Heger
 Assigned To: Emmanuel Bourg
 Fix For: 1.5

 Attachments: Config-269_test.diff, properties.patch


 PropertiesConfiguration.save() ignores the delimiter parsing disabled flag 
 and escapes all delimiter characters it encounters. When the configuration is 
 loaded again (with delimiter parsing disabled) the values of affected 
 properties contain the escaping character.
 This bug is very similar to CONFIGURATION-268, but for 
 PropertiesConfiguration.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-164) Charset detection


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-164:
-

Fix Version/s: (was: 1.5)
   1.6
  Environment: (was: Operating System: All
Platform: All)

 Charset detection
 -

 Key: CONFIGURATION-164
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-164
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: Nightly Builds
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 1.6


 Detecting automatically the charset of the file based configurations would be 
 a
 nice addition. When the file has no byte order mark defining the charset, we
 might apply a detection algorithm similar to the one implemented in Mozilla.
 There is at least one Java library providing this feature, jchardet :
 http://sourceforge.net/projects/jchardet

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-175) Support Byte Order Marks


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-175:
-

Fix Version/s: (was: 1.5)
   1.6
  Environment: (was: Operating System: All
Platform: All)

 Support Byte Order Marks
 

 Key: CONFIGURATION-175
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-175
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: Nightly Builds
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 1.6


 We should support byte order marks to detect automatically unicode files and
 parse them with the appropriate encoding. Here is a description of BOMs:
 http://en.wikipedia.org/wiki/Byte_Order_Mark
 I suggest the following changes:
 - add a setUseByteOrderMark() method in FileConfiguration to specify if the 
 BOM
 should be added when the file is saved
 - the useByteOrderMark flag is ignored if the encoding has no corresponding 
 BOM
 - on loading the file, look for a BOM at the beginning of the file and set the
 useByteOrderMark flag to true and switch to the corresponding encoding. The 
 flag
 is set to false by default

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (CONFIGURATION-249) save to URLs with a protocol other than file:


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg resolved CONFIGURATION-249.
--

Resolution: Fixed

The fix is now fully tested

 save to URLs with a protocol other than file:
 ---

 Key: CONFIGURATION-249
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-249
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.4
Reporter: Anselm Kruis
 Assigned To: Emmanuel Bourg
Priority: Minor
 Fix For: 1.5


 Currently, the save(URL) method from AbstractFileConfiguration only supports 
 file: URLs. 
 Why not support  writing to URLs too? It is as simple like this
   java.net.URLConnection connection = 
 url.openConnection();
   connection.setDoOutput(true);
   connection.setDoInput(false);
   save(connection.getOutputStream());
 I could prepare a patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-269) PropertiesConfiguration.save() generates superfluous escaping character when delimiter parsing is disabled

[
https://issues.apache.org/jira/browse/CONFIGURATION-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Emmanuel Bourg updated CONFIGURATION-269:
-

Attachment: properties.patch

Here is the patch I have in mind :

- If the list delimiter is disabled, forcing single lines has no effect, and
the list properties are written on several lines. It doesn't make sense to
disable the delimiter and expect list properties to be saved on a single line.
If the user really wants single line properties to remain compatible with the
standard Properties format, he has to enable the delimiter and change it to
something else, like the pipe character.

- PropertiesWriter doesn't escape the delimiter if the delimiter is null. This
is a simple change that avoid adding a state to PropertiesWriter (delimiter
enabled/disabled) or a reference to the parent configuration.

PropertiesConfiguration.save() generates superfluous escaping character when
delimiter parsing is disabled
--

Key: CONFIGURATION-269
URL: https://issues.apache.org/jira/browse/CONFIGURATION-269
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Oliver Heger
Assigned To: Oliver Heger
Fix For: 1.5

Attachments: properties.patch

PropertiesConfiguration.save() ignores the delimiter parsing disabled flag
and escapes all delimiter characters it encounters. When the configuration is
loaded again (with delimiter parsing disabled) the values of affected
properties contain the escaping character.
This bug is very similar to CONFIGURATION-268, but for
PropertiesConfiguration.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-271) BaseConfiguration duplicates multi value keys values


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497977
 ] 

Emmanuel Bourg commented on CONFIGURATION-271:
--

Could you add an example of the expected behavior ?

 BaseConfiguration duplicates multi value keys values
 

 Key: CONFIGURATION-271
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-271
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Daniel Adrian

 In addPropertyDirect(String key, Object value) the method adds the new value 
 to the property.
 If the property has the same value in the list, it will get duplicated.
 The method should check if the list contains the value and only if the result 
 is false add the value. 
 There is no logic in saving a multi value key with more than one instance of 
 a value.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-271) BaseConfiguration duplicates multi value keys values


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-271:
-

Fix Version/s: 1.5

 BaseConfiguration duplicates multi value keys values
 

 Key: CONFIGURATION-271
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-271
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Daniel Adrian
 Fix For: 1.5


 In addPropertyDirect(String key, Object value) the method adds the new value 
 to the property.
 If the property has the same value in the list, it will get duplicated.
 The method should check if the list contains the value and only if the result 
 is false add the value. 
 There is no logic in saving a multi value key with more than one instance of 
 a value.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-270) INIConfiguration Does not support multi value keys


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-270:
-

Fix Version/s: 1.5

And the corollary of using getString() is that interpolation variables are 
lost. Thank your for spotting this issue Daniel.

 INIConfiguration Does not support multi value keys
 --

 Key: CONFIGURATION-270
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-270
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Daniel Adrian
 Fix For: 1.5


 The INIConfiguration save(Writer writer) uses PrintWriter instead of using a 
 class like PropertiesConfiguration.PropertiesWriter.
 Because of that the method uses getString(String key) to get the keys value 
 (which return onlt the first element of the list) and in doing so there is no 
 support for multi value keys.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-272) ConfigurationUtils.copy results in escaped , characters no longer being escaped


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-272:
-

Fix Version/s: 1.5

 ConfigurationUtils.copy results in escaped , characters no longer being 
 escaped
 -

 Key: CONFIGURATION-272
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-272
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
 Environment: commons 1.4
Reporter: John Meagher
 Fix For: 1.5


 When using ConfigurationUtils.copy to go between configuration formats any 
 escaped out , characters are put into the output configuration without the 
 escape character.  This results in a different value being returned from 
 getString calls as it now things the property is a list.  If 4 escape 
 characters are used instead of the expected 1 then the copy will end up with 
 the correct value, but then the original will end up with the escape 
 character as part of the property value.  
 Example:
 SomeLongProperty=This is a test\, it is only a test
 # Ends up right in the copy, but not right in the original
 SomeOtherProperty=This is also a test, it is also only a test
 After copy:
 # Missing \ before ,
 SomeLongProperty=This is a test, it is only a test
 SomeOtherProperty=This is also a test\, it is also only a test

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-272) ConfigurationUtils.copy results in escaped , characters no longer being escaped


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497999
 ] 

Emmanuel Bourg commented on CONFIGURATION-272:
--

ConfigurationUtils.copy() calls setProperty on the target configuration with 
the value returned from getProperty() on the source configuration. The target 
configuration performs a new value parsing but it should not. A workaround is 
to disable the parsing of the delimiter before copying, and restore it after 
the copy :

target.setDelimiterParsingDisabled(true);
ConfigurationUtils.copy(source, target);
target.setDelimiterParsingDisabled(false);

 ConfigurationUtils.copy results in escaped , characters no longer being 
 escaped
 -

 Key: CONFIGURATION-272
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-272
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
 Environment: commons 1.4
Reporter: John Meagher
 Fix For: 1.5


 When using ConfigurationUtils.copy to go between configuration formats any 
 escaped out , characters are put into the output configuration without the 
 escape character.  This results in a different value being returned from 
 getString calls as it now things the property is a list.  If 4 escape 
 characters are used instead of the expected 1 then the copy will end up with 
 the correct value, but then the original will end up with the escape 
 character as part of the property value.  
 Example:
 SomeLongProperty=This is a test\, it is only a test
 # Ends up right in the copy, but not right in the original
 SomeOtherProperty=This is also a test, it is also only a test
 After copy:
 # Missing \ before ,
 SomeLongProperty=This is a test, it is only a test
 SomeOtherProperty=This is also a test\, it is also only a test

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-271) BaseConfiguration duplicates multi value keys values


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498025
 ] 

Emmanuel Bourg commented on CONFIGURATION-271:
--

I guess you merge the files by loading twice the same configuration instance ? 
Something like this :

INIConfiguration config = new INIConfiguration();
config.load(file1.ini);
config.load(file2.ini);
config.save(file1.ini);

Multi value properties have a list semantic and not a set semantic (i.e no 
duplicates), this is not something that can be changed. The best is to use 
another method to merge your properties. Here is an example of a function 
merging 2 configurations and eliminating redundant values :

public void merge(Configuration source, Configuration target)
{
Iterator keys = source.getKeys();
while (keys.hasNext())
{
String key = (String) keys.next();

Object value1 = source.getProperty(key);
Object value2 = target.getProperty(key);

if (value2 == null) {
target.setProperty(key, value1);
} else {
Set values = new HashSet();

if (value1 instanceof Collection) {
values.addAll((Collection) value1);
} else {
values.add(value1);
}

if (value2 instanceof Collection) {
values.addAll((Collection) value2);
} else {
values.add(value2);
}

target.setProperty(key, values);
}
}
}

 BaseConfiguration duplicates multi value keys values
 

 Key: CONFIGURATION-271
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-271
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Daniel Adrian
 Fix For: 1.5


 In addPropertyDirect(String key, Object value) the method adds the new value 
 to the property.
 If the property has the same value in the list, it will get duplicated.
 The method should check if the list contains the value and only if the result 
 is false add the value. 
 There is no logic in saving a multi value key with more than one instance of 
 a value.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r540562 - in /jakarta/commons/proper/configuration/trunk: project.xml src/java/org/apache/commons/configuration/AbstractFileConfiguration.java src/test/org/apache/commons/configuration

2007-05-22 Thread Emmanuel Bourg


Oliver Heger a écrit :


The new dependencies again cause the build under JDK 1.3 to fail because 
of a wrong class version.


Are these additional dependencies really necessary? Okay, they are used 
for testing only, but maybe it would be good to keep the length of our 
dependency list (at least somewhat) limited.


Got caught again, sorry. I'll fix that.

I don't mind adding test dependencies if it improves our coverage, but 
it's becoming more difficult to find external libraries still working 
with Java 1.3 :(


Emmanuel Bourg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (CONFIGURATION-270) INIConfiguration Does not support multi value keys


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg resolved CONFIGURATION-270.
--

Resolution: Fixed

 INIConfiguration Does not support multi value keys
 --

 Key: CONFIGURATION-270
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-270
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Daniel Adrian
 Assigned To: Emmanuel Bourg
 Fix For: 1.5


 The INIConfiguration save(Writer writer) uses PrintWriter instead of using a 
 class like PropertiesConfiguration.PropertiesWriter.
 Because of that the method uses getString(String key) to get the keys value 
 (which return onlt the first element of the list) and in doing so there is no 
 support for multi value keys.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-269) PropertiesConfiguration.save() generates superfluous escaping character when delimiter parsing is disabled

2007-05-21 Thread Emmanuel Bourg (JIRA)


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497582
 ] 

Emmanuel Bourg commented on CONFIGURATION-269:
--

The best solution is to split the property on several lines.

I can work on this Oliver if you haven't started yet.

 PropertiesConfiguration.save() generates superfluous escaping character when 
 delimiter parsing is disabled
 --

 Key: CONFIGURATION-269
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-269
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Oliver Heger
 Assigned To: Oliver Heger
 Fix For: 1.5


 PropertiesConfiguration.save() ignores the delimiter parsing disabled flag 
 and escapes all delimiter characters it encounters. When the configuration is 
 loaded again (with delimiter parsing disabled) the values of affected 
 properties contain the escaping character.
 This bug is very similar to CONFIGURATION-268, but for 
 PropertiesConfiguration.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-268) XMLConfiguration does not fully support disabled delimiter parsing

2007-05-10 Thread Emmanuel Bourg (JIRA)


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494703
 ] 

Emmanuel Bourg commented on CONFIGURATION-268:
--

That looks a bit weird to introduce a secondary list delimiter to disable the 
primary list delimiter. Why not letting the user change the delimiter himself ? 
We might add a note in the javadoc suggesting that 
setDelimiterParsingDisabled(true) is not recommended if list properties are 
used in attributes, and that changing the list delimiter to an untypical 
character is preferred.



 XMLConfiguration does not fully support disabled delimiter parsing
 --

 Key: CONFIGURATION-268
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-268
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Oliver Heger
 Assigned To: Oliver Heger
 Fix For: 1.5


 A call to setDelimiterParsingDisabled(true) should completely turn off the 
 mechanism for searching for list delimiters and splitting property values.
 However XMLConfiguration.save() escapes list delimiters even in this mode. 
 When later such a configuration file is loaded and delimiter parsing is 
 turned off, the values of affected properties will contain the escape 
 character.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-268) XMLConfiguration does not fully support disabled delimiter parsing

2007-05-07 Thread Emmanuel Bourg (JIRA)


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494011
 ] 

Emmanuel Bourg commented on CONFIGURATION-268:
--

And what about generating 2 elements ?

test attr=1,2,3/
test attr=4,5,6/



 XMLConfiguration does not fully support disabled delimiter parsing
 --

 Key: CONFIGURATION-268
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-268
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Oliver Heger
 Assigned To: Oliver Heger
 Fix For: 1.5


 A call to setDelimiterParsingDisabled(true) should completely turn off the 
 mechanism for searching for list delimiters and splitting property values.
 However XMLConfiguration.save() escapes list delimiters even in this mode. 
 When later such a configuration file is loaded and delimiter parsing is 
 turned off, the values of affected properties will contain the escape 
 character.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] Going TLP?

2007-05-02 Thread Emmanuel Bourg

Sorry for the dumb question, I may have missed an important thread, but 
what do we gain exactly by moving to a TLP ? What will be different ? I 
can see the external aspects like a new web site, new mailing lists and 
the loss of the Jakarta brand, but I doubt we are moving just for this. 
Will this new structure help us attract more users or more contributors, 
and how ? Will we release more components, more frequently ? Will this 
improve the quality and the visibility of the projects ?


Thank you for enlightening me.

Emmanuel Bourg




Henri Yandell a écrit :

I think the end should be nigh for Jakarta (those on private@ will
have seen a thread in which I side-topic'd with the feeling that the
end should be nigh for Jakarta). Previously I've suggested that
Commons should flatten into Jakarta and that Jakarta should become a
general 'Java components' project; however there are some negatives to
that that I think are critical.

Firstly, it leaves the future Jakarta with a lot of dead projects that
are going nowhere. That's not going to change in the short to medium
term, so it just becomes a millstone for the project's neck.

Secondly, the Jakarta PMC will always remain a big group of people who
care about the brand name and the various legacies, rather than a
small focused PMC. I think this isn't desirable for any active
community that are a part of Jakarta currently - trying to have a PMC
that are acting as one community when not being one community doesn't
work.

Thirdly, I think by being here we are helping to delay the inevitable
and keeping the old, broken umbrella going. Moving to TLP will help
things move along, and will provide a place for things to move to.

So with that said - I'd like to propose that we move to commons.apache.org.

Hen

-
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]

Re: [nightly build] [configuration]

2007-05-01 Thread Emmanuel Bourg


Thanks a lot Phil !

Phil Steitz a écrit :

I finally got things configured so that [configuration] will build
along with the other m1 nightlies.  The problem is that - IIUC and C
may well be off -  in m1, you can upgrade plugins selectively via
version specifications in the pom, but you can't downgrade them.  As
long as the 1.9.2 xdoc plugin is installed locally, m1 will load it
and that will hose the [configuration] build.  Workaround is to
explicitly install 1.8 using maven plugin:download -DgroupId=maven
-DartifactId=maven-xdoc-plugin -Dversion=1.8.  That uninistalls 1.9.2,
but as long as other components have 1.9.2 specified in their poms, m1
will cache and use 1.9.2 for them.  This works4me locally and on
vmbuild. Anyone else wanting to build [configuration] as well as other
commons components will likely have to do the same.

Moral of the story - let's get going on m2 ;-).  Once a component has
a working m2 build, to move the nightlies to m2, just move it from
commons-nightly/trunk/nightly_proper_maven_list.txt to
commons-nightly/trunk/nightly_proper_maven2_list.txt
(or _sandbox_ for sandbox components).

I also got the wget working on people, so the nightly tarballs / zips
are back again at
http://people.apache.org/builds/jakarta-commons/nightly/
Next step is to do same for maven snapshot jars.

Phil

-
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]

[jira] Commented: (CONFIGURATION-253) FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491581
 ] 

Emmanuel Bourg commented on CONFIGURATION-253:
--

If the URL and the basepath are set on calling load(), then this is a bug since 
the source should not change.

If we have to change the current behavior, I prefer that load() changes the 
source only if no source is already set.

 FileConfiguration getFile(), getFileName(), getBasePath() are not always 
 consistent
 ---

 Key: CONFIGURATION-253
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-253
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Thomas Wabner
 Fix For: 1.5


 Taken from the maillinglist:
  I have a properties configuration which is loaded without a problem.
  Later in my application I will access the file which is aligned to 
  this configuration.
  
   
  
  final IFileConfiguration _productConf = 
  _conf.getProductConfigurations().get(_productId);
  
  log.debug(product conf file  + _productConf.getFile());
  
  log.debug(product conf filename  + _productConf.getFileName());
  
  log.debug(product conf base path  + _productConf.getBasePath());
  
   
  
  The methods _productConf.getFile() and _productConf.getFileName() 
  returning null but the getBasePath() returns a path which is correct 
  (like file:/C:/Projects/workspace/myProject/project.properties). Seems 
  for me like a bug because the PropertiesConfiguration is loaded 
  correct and works.
  
   
  
  By side: I have also set a file reloading strategy for this 
  configuration.
  
   
  
  Any ideas what's happen in this case or where I can find the problem? 
  It would be nicer to get the File() instead the BasePath which has to 
  be converted into a URL before I can access the whole properties file.
  
   
  
  Thanks in advance,
  
   
  
  - Thomas Wabner
  
  
 Thomas,
 you are right, the conversions between a base path, a file name, and a File 
 are not always consistent. How did you load the configuration (this 
 determines, which internal fields are set)?
 I would recommend to work with URLs, i.e. the method getURL(). A file-based 
 configuration's URL is always defined.
 If you like, you can open a Jira ticket for this problem.
 Thanks.
 Oliver
 The file is loaded in this way:
 _productConf = new ProductConfiguration();
 _productConf.load(FileTools.getPathForList(_propductPathList).getPath());
 means the load method gets an String and not an File.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-224) BaseConfiguration.getProperty() returns reference to intenal store collection object instead of a clone


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491590
 ] 

Emmanuel Bourg commented on CONFIGURATION-224:
--

There is another alternative to this issue : getProperty() could return a 
decorator for Collection properties, the decorator would intercept the 
modifications to the collection and generate a configuration event.

That may be interesting for the getList() methods, I think it's important that 
getProperty() returns the stored object without modification.

 BaseConfiguration.getProperty() returns reference to intenal store collection 
 object instead of a clone
 ---

 Key: CONFIGURATION-224
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-224
 Project: Commons Configuration
  Issue Type: Bug
 Environment: 1.3RC2
Reporter: Gabriele Garuglieri
Priority: Minor
 Fix For: 1.3

 Attachments: list.patch


 When the property object is a List or an Array, 
 BaseConfiguration.getProperty() returns a reference to the object contained 
 in the store.
 This means that changing that object, changes the content of the properties 
 store without an explicit setProperty() or addProperty(). 
 Also any change to the object in the store will change the object that the 
 code has reference to, but the user is not aware that the property has 
 changed unless he has added a ConfigurationListener.
 Attached a patch to make the object returned by 
 BaseConfiguration.getProperty() a clone of store content, to avoid side 
 effects when changing Collection properties.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-253) FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491778
 ] 

Emmanuel Bourg commented on CONFIGURATION-253:
--

That looks good, the structure of the chained else/if could even be simplified.

 FileConfiguration getFile(), getFileName(), getBasePath() are not always 
 consistent
 ---

 Key: CONFIGURATION-253
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-253
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Thomas Wabner
 Assigned To: Oliver Heger
 Fix For: 1.5


 Taken from the maillinglist:
  I have a properties configuration which is loaded without a problem.
  Later in my application I will access the file which is aligned to 
  this configuration.
  
   
  
  final IFileConfiguration _productConf = 
  _conf.getProductConfigurations().get(_productId);
  
  log.debug(product conf file  + _productConf.getFile());
  
  log.debug(product conf filename  + _productConf.getFileName());
  
  log.debug(product conf base path  + _productConf.getBasePath());
  
   
  
  The methods _productConf.getFile() and _productConf.getFileName() 
  returning null but the getBasePath() returns a path which is correct 
  (like file:/C:/Projects/workspace/myProject/project.properties). Seems 
  for me like a bug because the PropertiesConfiguration is loaded 
  correct and works.
  
   
  
  By side: I have also set a file reloading strategy for this 
  configuration.
  
   
  
  Any ideas what's happen in this case or where I can find the problem? 
  It would be nicer to get the File() instead the BasePath which has to 
  be converted into a URL before I can access the whole properties file.
  
   
  
  Thanks in advance,
  
   
  
  - Thomas Wabner
  
  
 Thomas,
 you are right, the conversions between a base path, a file name, and a File 
 are not always consistent. How did you load the configuration (this 
 determines, which internal fields are set)?
 I would recommend to work with URLs, i.e. the method getURL(). A file-based 
 configuration's URL is always defined.
 If you like, you can open a Jira ticket for this problem.
 Thanks.
 Oliver
 The file is loaded in this way:
 _productConf = new ProductConfiguration();
 _productConf.load(FileTools.getPathForList(_propductPathList).getPath());
 means the load method gets an String and not an File.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-159) Save the changes made to a CompositeConfiguration


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491785
 ] 

Emmanuel Bourg commented on CONFIGURATION-159:
--

I'm thinking about adding a flush() method to the Configuration interface 
similar to the flush() method in the Preferences API :

http://java.sun.com/javase/6/docs/api/java/util/prefs/Preferences.html#flush()

The concept of making the changes persistent is not specific to the file 
configurations, we need it here for CompositeConfiguration, and we'll need it 
for DatabaseConfiguration to implement the caching mechanism.




 Save the changes made to a CompositeConfiguration
 -

 Key: CONFIGURATION-159
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-159
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.0
 Environment: Operating System: All
 Platform: All
Reporter: Sagar Kar
Priority: Minor
 Fix For: 1.5


 Hi,
 I used a CompositeConfiguration object to load all my properties and xml 
 files.
 I expose these configuration properties in a JMX console.
 These properties coming from many different files can be modified at runtime 
 in
 memory. But I need to store these back to the original files from where they
 were picked, so that I dont loose them if the server is restarted.
 The problem that I faced is whenever a property is being modified, it gets 
 moved
 from the original configuration to a BaseConfiguration object.
 What I would like is the change being made to the original configuration 
 object
 as well.
 Thanks ,
 Sagar

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-262) Binary property list format


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-262:
-

Fix Version/s: (was: 1.5)
   1.6

 Binary property list format
 ---

 Key: CONFIGURATION-262
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-262
 Project: Commons Configuration
  Issue Type: New Feature
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 1.6

 Attachments: CFBinaryPList.c


 With OS X 10.4 Apple introduced a variant of the plist format that is 
 compressed using a binary format. That would be nice to support this format 
 with a BinaryPropertyListConfiguration class.
 I haven't found the specification of this format. 
 The plutil tool can be used to convert between xml and binary plist files.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-258) JSON configuration


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-258:
-

Fix Version/s: (was: 1.5)
   1.6
  Environment: (was:
« Hide
Operating System: All
Platform: All
)

 JSON configuration
 --

 Key: CONFIGURATION-258
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Antonio López-Cerón Vivo
Priority: Minor
 Fix For: 1.6


 JSON  is a lightweight data-interchange format
 {menu: {
   id: file,
   value: File,
   popup: {
 menuitem: [
   {value: New, onclick: CreateNewDoc()},
   {value: Open, onclick: OpenDoc()},
   {value: Close, onclick: CloseDoc()}
 ]
   }
 }}
 All references can be located at
 http://www.json.org/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-180) Cache DatabaseConfiguration values for higher performance

[
https://issues.apache.org/jira/browse/CONFIGURATION-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491813
]

Emmanuel Bourg commented on CONFIGURATION-180:
--

I see several solutions to improve the performances by caching the properties.
We may either :

1. load the entire configuration in memory. A flush() method would save the
new/modified properties back to the database, a sync() method would reload the
properties. That may be nice to reuse the reloading strategies but currently
they are specific to the file configurations, that will require some
refactoring.

2. keep in memory the properties read for a certain time. getProperty(foo)
will hit the database only if foo was read more than 5 minutes ago for example.
The delay would be adjustable. Setting a property would still hit the database
directly.

3. same as 2, but the configuration is preloaded once.

The caching should be optional to preserve the current behavior if needed.

Cache DatabaseConfiguration values for higher performance
-

Key: CONFIGURATION-180
URL: https://issues.apache.org/jira/browse/CONFIGURATION-180
Project: Commons Configuration
Issue Type: Improvement
Reporter: Stephen Cooper
Assigned To: Emmanuel Bourg
Priority: Minor
Fix For: 1.5

Attachments: dbpreload.txt, Enhancement33553.checkstyle.patch,
Enhancement33553.patch

The DatabaseConfiguration class queries each property as it gets the request
for each property. This is
nice for ensuring that you're always up to date, but it doesn't give very
good performance in enterprise
applications, where the database may not be on the same subnet.
What we need is the ability to hit the database once, get all the keys/values
and then serve up
getString etc. from that cache.
I'll be opening a separate enhancement to have a generic Reloading Strategy
which could then be
applied to this caching DatabaseConfiguration approach.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-126) [configuration] SubsetConfiguration.getList throws exception


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-126:
-

Fix Version/s: 1.0
  Environment: (was: Operating System: other
Platform: All)

 [configuration] SubsetConfiguration.getList throws exception
 

 Key: CONFIGURATION-126
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-126
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
Reporter: Joerg Schaible
Priority: Blocker
 Fix For: 1.0

 Attachments: get-list.diff


 SubsetConfiguration.getList is not usable anymore, method(s) throw always a
 ClassCastException claiming ArrayList is not a List!
 Will add patch for test case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-27) [configuration] subset method on xml configuration does not work as expected


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-27:


Fix Version/s: 1.2
  Description: (was:  )
  Environment: (was: Operating System: All
Platform: All)

 [configuration] subset method on xml configuration does not work as expected
 

 Key: CONFIGURATION-27
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-27
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Fabien Nisol
Priority: Blocker
 Fix For: 1.2




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-89) [configuration] Setting the reloading strategy to FileChangedReloadingStrategy erases entire configuration


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-89:


Fix Version/s: 1.2

 [configuration] Setting the reloading strategy to 
 FileChangedReloadingStrategy erases entire configuration
 --

 Key: CONFIGURATION-89
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-89
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: Windows XP
 Platform: PC
Reporter: Blaine R Southam
Priority: Critical
 Fix For: 1.2

 Attachments: AbstractFileConfiguration.diff, 
 TestFileConfiguration.diff


 When setting a PropertiesConfiguration reloading strategy to
 FileChangedReloadingStrategy - the entire configuration is erased.
 The problem is that when the FileChangedReloadingStrategy is set, the
 configuration file is erased and then reloaded and then written out.
 The file is erased in AbstractFileConfiguration.save(File) when a new
 FileOutputStream is created.  Then in the PropertiesConfiguration.save(Writer)
 the call to getKeys() causes a reaload() to occur (which the strategy says 
 needs
 to be reloaded because it has been modified).  But the saved config file is 
 now
 zeroed out by the new file stream, and it is read in as an empty config.
 Here is a testcase that exposed this defect:
 public void
 testPropertiesConfigurationWithFileChangedReloadingStrategyDefect() throws
 ConfigurationException, FileNotFoundException, IOException {
 FileWriter file = new FileWriter(testfile.properties);
 file.write(a=1);
 file.close();
 FileConfiguration config = new
 PropertiesConfiguration(testfile.properties);
 config.setAutoSave(true);
 config.setReloadingStrategy(new FileChangedReloadingStrategy());
 assertEquals(1, config.getString(a));
 config.setProperty(2, b);
 assertEquals(1, config.getString(a));
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-23) [Configuration] Property throwExceptionOnMissing is not respected for subsets


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-23:


Fix Version/s: 1.0
  Environment: (was: Operating System: All
Platform: All)

 [Configuration] Property throwExceptionOnMissing is not respected for subsets
 -

 Key: CONFIGURATION-23
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-23
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
Reporter: Joerg Schaible
Priority: Critical
 Fix For: 1.0


 public void testNoSuchElementExceptionFoSubsets() {
 BaseConfiguration config = new BaseConfiguration();
 config.setThrowExceptionOnMissing(true);
 config.addProperty(subset.foo, bar);
 try {
 config.getString(subset.foobar);
 fail(NoSuchElementException expected);
 } catch(NoSuchElementException e) {
 // expected
 }
 try {
 config.subset(subset).getString(foobar);
 fail(NoSuchElementException expected);
 } catch(NoSuchElementException e) {
 // expected
 }
 }
 This behaviour is currently a showstopper, since I rely on the thrown 
 exception.
 Note: subset() returns a plain Configuration interface, that does not have the
 setThrowExceptionOnMissing setter.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-6) [configuration] XMLConfiguration inconsistency towards empty values


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-6:
---

Fix Version/s: 1.2
  Environment: (was: Operating System: other
Platform: All)

 [configuration] XMLConfiguration inconsistency towards empty values
 ---

 Key: CONFIGURATION-6
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-6
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Etienne Lacazedieu
 Fix For: 1.2


 Empty values are not read correctly from XML files : when a XML file contains 
 an
 empty element, the corresponding keys are not present in the configuration, 
 but
 an empty string can be saved!
 Consider the following code : 
 XMLConfiguration config = new XMLConfiguration();
 config.setProperty(foo.bar, );
 config.save(config.xml);
 System.out.println(Config saved!);
 System.out.println(foo.bar in config1 = +config.getProperty(foo.bar));
 XMLConfiguration config2 = new XMLConfiguration(config.xml);
 System.out.println(foo.bar in config2= +config2.getProperty(foo.bar));
 The output is : 
 foo.bar in config1 = ''
 foo.bar in config2 = 'null'
 the file config.xml contains : 
 configuration
 foo
  bar/
 /foo
 /configuration
 this also does not allow to distinguish between an empty value and a missing 
 key.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-2) [configuration] [1.2RC1] ConfigurationDynaBean may implement java.util.Map


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-2:
---

Fix Version/s: 1.2

 [configuration] [1.2RC1] ConfigurationDynaBean may implement java.util.Map
 --

 Key: CONFIGURATION-2
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-2
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: other
 Platform: Other
Reporter: nicolas de loof
 Fix For: 1.2


 ConfigurationDynaBean says 
 It also implements a Map interface so that it can be used in JSP 2.0 
 Expression
 Language expressions.
 Map interface is not implemented (in 1.2RC1) and ConfigurationDynaBean cannot 
 be
 used from EL :
 c:out value=${configuration['un.test']}/ :
 Unable to find a value for un.test in object of class
 org.apache.commons.configuration.beanutils.ConfigurationDynaBean using
 operator [] (null)
 Simply implementing Map.get(Object) may solve the problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-33) [configuration] Clarify ReloadingStrategy interface usage


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-33:


Fix Version/s: 1.2
  Environment: (was: Operating System: other
Platform: Other)

 [configuration] Clarify ReloadingStrategy interface usage
 -

 Key: CONFIGURATION-33
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-33
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
Reporter: nicolas de loof
 Fix For: 1.2


 I had some trouble creating a ReloadingStrategy implementation (based on a JMX
 reload request) : 
 reloadingRequired() is called several times AFTER first returning 'true' and
 before reloadingPerformed() is called. In fact, reloading process requires
 access to getProperty() that itself (re)enters reload. If reloadingRequired()
 doens't return false at this time, a infinite recursice loop starts.
 Perhaps it is a reload() bug, that may use a boolean flag to mark
 processing-reload and avoid such infinite loop in the Thread runing he reload.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-36) [configuration] HierarchicalConfiguration.getKeys(String) might return empty iterator


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-36:


Fix Version/s: 1.1

 [configuration] HierarchicalConfiguration.getKeys(String) might return empty 
 iterator
 -

 Key: CONFIGURATION-36
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-36
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.0
 Environment: Operating System: other
 Platform: Other
Reporter: Oliver Heger
 Fix For: 1.1

 Attachments: hierarchicalconfig.txt, HierarchicalConfiguration.txt, 
 testhierarchicalconfig.txt, TestHierarchicalConfiguration.txt, 
 TestSubsetConfiguration.txt


 If called with a prefix string that contains indices, the implementation of
 getKeys(String) inherited from AbstractConfiguration fails to find keys with 
 the
 passed in prefix. So the returned iterator is empty.
 This patch provides a specific implementation of this method for
 HierarchicalConfiguration that solves this problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-35) [configuration] PropertiesConfiguration.load should default to encoding 8859_1


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-35:


Fix Version/s: 1.2

 [configuration] PropertiesConfiguration.load should default to encoding 
 8859_1
 

 Key: CONFIGURATION-35
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-35
 Project: Commons Configuration
  Issue Type: Bug
 Environment: Operating System: other
 Platform: Other
Reporter: Will Glass-Husain
 Fix For: 1.2


 Same issue as:
 http://issues.apache.org/bugzilla/show_bug.cgi?id=17616
 Copied from 17616
 The default load method for commons.collections.ExtendedProperties currently 
 loads properties using the default JVM encoding.  The default load() method 
 should use 8859_1 encoding.
 Rationale:
 1) consistency: java.util.Properties.load() method always uses 8859_1
 2) properties resources are always 8859_1, by convention.
 2) On edbcic machines, particularly IBM mainframes, the default encoding is 
 Cp1047 (ebcdic), but properties files are always ASCII (ISO8859-1)
 3) This bug causes many Apache tools, such as Velocity, which uses 
 commons.collections, to fail on non-ascii machines, since they distribute 
 properties resources which are (correctly) in 8859-1.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-37) [configuration] DOMConfiguration can't replace DOM4JConfiguration


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-37:


Fix Version/s: 1.0

 [configuration] DOMConfiguration can't replace DOM4JConfiguration
 -

 Key: CONFIGURATION-37
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-37
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: All
 Platform: All
Reporter: Emmanuel Bourg
 Fix For: 1.0


 I tried to replace DOM4JConfiguration in the ConfigurationFactory with
 DOMConfiguration:
 @@ -281,7 +281,7 @@
  setupDigesterInstance(
  digester,
  matchString + dom4j,
 -new BasePathConfigurationFactory(DOM4JConfiguration.class),
 +new BasePathConfigurationFactory(DOMConfiguration.class),
  METH_LOAD,
  additional);
  setupDigesterInstance(
 But one test breaks in TestConfigurationFactory:
 Testcase:
 testAllConfiguration(org.apache.commons.configuration.TestConfigurationFactory):
   Caused
 an ERROR
 SAX Exception caught
 org.apache.commons.configuration.ConfigurationException: SAX Exception caught
   at
 org.apache.commons.configuration.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:164)
   at
 org.apache.commons.configuration.TestConfigurationFactory.testAllConfiguration(TestConfigurationFactory.java:229)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 Caused by: org.apache.commons.configuration.ConfigurationException: Could not
 load from
 D:\dev\apache\jakarta-commons\configuration\file:\D:\dev\apache\jakarta-commons\configuration\conf\testDigesterConfiguration3.xml\test.xml
   at 
 org.apache.commons.digester.Digester.createSAXException(Digester.java:2540)
   at 
 org.apache.commons.digester.Digester.createSAXException(Digester.java:2566)
   at org.apache.commons.digester.Digester.endElement(Digester.java:1061)
   at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown 
 Source)
   at 
 org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown 
 Source)
   at
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
 Source)
   at
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
 Source)
   at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
   at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
   at org.apache.commons.digester.Digester.parse(Digester.java:1567)
   at
 org.apache.commons.configuration.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:158)
   ... 15 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-38) [configuration][patch]Removed JDK 1.4 dependency


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-38:


Fix Version/s: 1.0

 [configuration][patch]Removed JDK 1.4 dependency
 

 Key: CONFIGURATION-38
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-38
 Project: Commons Configuration
  Issue Type: Bug
 Environment: Operating System: other
 Platform: Other
Reporter: Oliver Heger
 Fix For: 1.0

 Attachments: ConfigurationKey.txt


 In ConfigurationKey class there have been two references to the
 StringBuffer.indexOf() method, which is new in JDK 1.4. This patch removes 
 this
 dependency.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-39) [configuration] FileChangedReloadingStrategy javadoc misleading

[
https://issues.apache.org/jira/browse/CONFIGURATION-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Emmanuel Bourg updated CONFIGURATION-39:

Fix Version/s: 1.2

[configuration] FileChangedReloadingStrategy javadoc misleading
---

Key: CONFIGURATION-39
URL: https://issues.apache.org/jira/browse/CONFIGURATION-39
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.1
Environment: Operating System: All
Platform: All
Reporter: John Nikolai
Priority: Trivial
Fix For: 1.2

The current javadoc for 1.1 version of Configuration is as follows:
-
A reloading strategy that will reload the configuration every time its
underlying file is changed. The file
is not reloaded more than once every 5 seconds by default, this time can be
changed by setting the
refresh delay. This strategy only works with FileConfiguration instances.
-
I was under the false impression that a thread would be created which would
periodically wake up every
5 seconds and poll the property file to see if it has changed or not. If the
file has changed then it would
be reloaded. However this is not the case. After diving into the code, you
need to call one of the get*()
methods (i.e. getInt(), getLong(), etc...) before the file is checked.
Finally, it would be nice to have some kind of callback mechanism to notify
listeners that implement a
well known interface defined in the configuration API that the file has
changed.
Thanks for all your hard work!

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-41) [configuration] Output format of FileConfiguration classes


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-41:


Fix Version/s: 1.2

 [configuration] Output format of FileConfiguration classes
 --

 Key: CONFIGURATION-41
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-41
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: Windows 2000
 Platform: Other
Reporter: Kay Doebl
 Fix For: 1.2

 Attachments: properties_lineseparator.patch, XML_encoding.patch


 I am using Commons Configuration 1.1.
 Saving 'FielConfiguration's the configuration files will be overwritten every 
 time.
 Bad if you have formatted them with descriptions and comments ... but this is
 not so important.
 Not so good is, that in the class:
 PropertiesConfiguration:
 '\n' is used as line separator and not the 
 System.getProperty(line.separator).
 So, on Windows systems the configuration files are badly readable.
 XMLConfiguration:
 The encoding is not looped though to the encoding in the XML head declaration.
 Every time UTF-8 is set (?xml version=1.0 encoding=UTF-8?)
 I would prefer that my encoding (setEncoding()) is reflected in the XML 
 document.
 Is there a reason that it is implemented like you do?
 Attached are patches which would resolve the problems (if you want):
 PropertiesConfiguration.java:
 properties_lineseparator.patch
 136a137,138
  private static final String lineSeparator =
 System.getProperty(line.separator);
  
 344c346
  out.write(\n);
 ---
  out.write(lineSeparator);
 349c351
  out.write(\n);
 ---
  out.write(lineSeparator);
 486c488
  write('\n');
 ---
  write(lineSeparator);
 511c513
  write(#  + comment + \n);
 ---
  write(#  + comment + lineSeparator);
 XMLConfiguration.java:
 XML_encoding.patch
 446a447
  transformer.setOutputProperty(OutputKeys.ENCODING, 
  getEncoding());

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-45) [configuration] Fails silently if asked to save to an invalid filename


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-45:


Fix Version/s: 1.1

 [configuration] Fails silently if asked to save to an invalid filename
 --

 Key: CONFIGURATION-45
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-45
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.0
 Environment: Operating System: All
 Platform: All
Reporter: Iain Shepherd
 Fix For: 1.1


 Running code like this...
 FileConfiguration config = new PropertiesConfiguration();
 config.setFile(new File(/invalid/path/my.properties));
 config.save();
 ...doesn't throw any Exception. AbstractFileConfiguration.save(File) swallows 
 the FileNotFoundException, prints a stack trace, and completes normally, 
 without having saved the file.
 Cheers
 Iain Shepherd

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-46) [Configuration] Documentation Issue


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-46:


Fix Version/s: 1.0

 [Configuration] Documentation Issue
 ---

 Key: CONFIGURATION-46
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-46
 Project: Commons Configuration
  Issue Type: Bug
 Environment: Operating System: other
 Platform: Other
Reporter: Tim Reilly
 Fix For: 1.0

 Attachments: examples-patch.txt


 I think there's an error in the documentation for commons-configuration 
 examples page.
 If I use this example:
ConfigurationFactory factory = new ConfigurationFactory();
URL configURL = getClass().getResource(/config.xml);
factory.setConfigurationFileName(configURL.toString());
Configuration config = factory.getConfiguration();
 I get a NPE, but if I change to this:
   ConfigurationFactory factory = new ConfigurationFactory();
   URL configURL = getClass().getResource(/config.xml);
 - factory.setConfigurationFileName(configURL.toString());
 + factory.setConfigurationFileName(configURL.getFile());
   Configuration config = factory.getConfiguration();
 everthing is fine. Basically, the setConfigFileName in ConfigurationFactory 
 is 
 not expecting a URI its expecting a path i think?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-49) [configuration] XMLConfiguration may lose attributes in its save() method


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-49:


Fix Version/s: 1.2

 [configuration] XMLConfiguration may lose attributes in its save() method
 -

 Key: CONFIGURATION-49
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-49
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: All
 Platform: All
Reporter: Oliver Heger
 Fix For: 1.2


 Under some circumstances (if a configuration is loaded, cleared and then
 reloaded), the save() method forgets to write attributes. Their values are 
 still
 contained in the configuration object itself, but they are not written to the
 output file.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-50) [configuration] FileChangedReloadingStrategy fails to properly detect file change


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-50:


Fix Version/s: 1.2

 [configuration] FileChangedReloadingStrategy fails to properly detect file 
 change
 -

 Key: CONFIGURATION-50
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-50
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: Windows XP
 Platform: Other
Reporter: Eric Lee
 Fix For: 1.2

 Attachments: ConfigurationChangedReloadingStrategy.java, 
 ConfigurationUtils.java.patch, patch.diff, patch.diff


 Two code examples that fail to detect / load file changes:
 =Sample
 1:  If properties file location is determined by searching the classpath,
 changes are not detected.
 try {
 PropertiesConfiguration propConfig = new
 PropertiesConfiguration(commons.properties);
 FileChangedReloadingStrategy strategy = new FileChangedReloadingStrategy();
 strategy.setConfiguration(propConfig);
 strategy.setRefreshDelay(500);
 strategy.init();
 for (;;){
 String prop1 = propConfig.getString(prop1);
 System.out.println(Calendar.getInstance().getTime() +  :  +
 strategy.reloadingRequired() +  :  + prop1);
 Thread.sleep(1000);
 }
 } catch (Throwable t){
 t.printStackTrace();
 }
 =
 Sample 2:  If properties file location is specified, changes are not detected
 but not loaded.
 try {
 PropertiesConfiguration propConfig = new
 PropertiesConfiguration(d:/tmp/commons.properties);
 FileChangedReloadingStrategy strategy = new FileChangedReloadingStrategy();
 strategy.setConfiguration(propConfig);
 strategy.setRefreshDelay(500);
 strategy.init();
 for (;;){
 String prop1 = propConfig.getString(prop1);
 System.out.println(Calendar.getInstance().getTime() +  :  +
 strategy.reloadingRequired() +  :  + prop1);
 Thread.sleep(1000);
 }
 } catch (Throwable t){
 t.printStackTrace();
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-54) [configuration] BaseConfiguration: containsKey ignores default properties


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-54:


Fix Version/s: 1.0

 [configuration] BaseConfiguration: containsKey ignores default properties
 -

 Key: CONFIGURATION-54
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-54
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: All
 Platform: All
Reporter: Christian Siefkes
 Fix For: 1.0


 The current (CVS Head) implementation of BaseConfiguration.containsKey does 
 not
 check whether a key is contained in the defaults Configuration (if exists).
 I think
 public boolean containsKey(String key)
 {
 return store.containsKey(key);
 }
 should be:
 public boolean containsKey(String key)
 {
 return store.containsKey(key)
|| ((defaults != null)  defaults.containsKey(key));
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-56) [configuration] Property substitution doesn't work for subsets anymore


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-56:


Fix Version/s: 1.0

 [configuration] Property substitution doesn't work for subsets anymore
 --

 Key: CONFIGURATION-56
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-56
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: other
 Platform: All
Reporter: Joerg Schaible
 Fix For: 1.0

 Attachments: CompositeConfiguration.java.diff, 
 project.properties.diff, SubsetConfiguration.java.diff, 
 SubsetConfiguration.java.diff, TestCompositeConfiguration.java.diff


 The last refactoring of the subsets eliminated the previously working property
 substitution by chance.
 Patches follow.
 CAUTION: The patches revert a workaround for HierarchicalConfiguration, which
 makes 'illegal' internal assuptions about the implementation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-58) [configuration] Wrong primitive conversion in DataConfiguration


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-58:


Fix Version/s: 1.1

 [configuration] Wrong primitive conversion in DataConfiguration
 ---

 Key: CONFIGURATION-58
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-58
 Project: Commons Configuration
  Issue Type: Bug
 Environment: Operating System: All
 Platform: All
Reporter: Emmanuel Bourg
 Fix For: 1.1


 The values in getLongArray(), getFloatArray() and getDoubleArray() are not
 converted to the right type, they are all converted into integers.
 Index: DataConfiguration.java
 ===
 --- DataConfiguration.java(revision 153417)
 +++ DataConfiguration.java(working copy)
 @@ -825,7 +826,7 @@
  Iterator it = values.iterator();
  while (it.hasNext())
  {
 -array[i++] = PropertyConverter.toLong(it.next()).intValue();
 +array[i++] = PropertyConverter.toLong(it.next()).longValue();
  }
  }
  else
 @@ -834,7 +835,7 @@
  {
  // attempt to convert a single value
  array = new long[1];
 -array[0] = PropertyConverter.toLong(value).intValue();
 +array[0] = PropertyConverter.toLong(value).longValue();
  }
  catch (ConversionException e)
  {
 @@ -974,7 +975,7 @@
  Iterator it = values.iterator();
  while (it.hasNext())
  {
 -array[i++] = PropertyConverter.toFloat(it.next()).intValue();
 +array[i++] = 
 PropertyConverter.toFloat(it.next()).floatValue();
  }
  }
  else
 @@ -983,7 +984,7 @@
  {
  // attempt to convert a single value
  array = new float[1];
 -array[0] = PropertyConverter.toFloat(value).intValue();
 +array[0] = PropertyConverter.toFloat(value).floatValue();
  }
  catch (ConversionException e)
  {
 @@ -1124,7 +1125,7 @@
  Iterator it = values.iterator();
  while (it.hasNext())
  {
 -array[i++] = 
 PropertyConverter.toDouble(it.next()).intValue();
 +array[i++] = 
 PropertyConverter.toDouble(it.next()).doubleValue();
  }
  }
  else
 @@ -1133,7 +1134,7 @@
  {
  // attempt to convert a single value
  array = new double[1];
 -array[0] = PropertyConverter.toDouble(value).intValue();
 +array[0] = PropertyConverter.toDouble(value).doubleValue();
  }
  catch (ConversionException e)
  {

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-60) [configuration] XML How-to needs to be updated for RC-1


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-60:


Fix Version/s: 1.0

 [configuration] XML How-to needs to be updated for RC-1
 ---

 Key: CONFIGURATION-60
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-60
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: other
 Platform: Other
Reporter: woodman
 Fix For: 1.0

 Attachments: howto.txt


 jakarta-commons\configuration\xdocs\howto_xml.xml needs to be updated to 
 match 
 the deliverables in RC-1.   The exclusion of ConfigurationXMLDocument is the 
 main thing I noticed that needs to be addressed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-61) [configuration] JNDIConfiguration and union configuration

[
https://issues.apache.org/jira/browse/CONFIGURATION-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Emmanuel Bourg updated CONFIGURATION-61:

Fix Version/s: 1.0

[configuration] JNDIConfiguration and union configuration
-

Key: CONFIGURATION-61
URL: https://issues.apache.org/jira/browse/CONFIGURATION-61
Project: Commons Configuration
Issue Type: Bug
Environment: Operating System: other
Platform: Other
Reporter: Oliver Heger
Fix For: 1.0

Attachments: testconfigurationfactory.txt,
testDigesterConfiguration3.xml

JNDIConfiguration seems not to work with ConfigurationFactory when used in the
additional section. The union configuration feature of ConfigurationFactory
is
implemented by calling getKeys() on a Configuration object, iterating through
the keys, and calling getProperty() for each.
JNDIConfiguration.getKeys() obviously always returns an empty iterator in my
tests though the Configuration object is not empty (getString() returns values
for some keys). I am not sure whether this is a bug in JNDIConfiguration or a
shortcomming of the JNDI implementation used for testing.
Another point is that JNDIConfiguration.getProperty() always throws a not
supported error. This would also blow ConfigurationFactory if getKeys()
returned
a valid iterator. I don't understand why this error is thrown. In my opinion
this is a violation of the contract defined by the Configuration interface
(the
same is true for some other methods).
Attached is an extension to the unit test of ConfigurationFactory that
demonstrates the problem.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-62) [configuration] Using FileChangedReloadingStrategy for XMLConfiguration


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-62:


Fix Version/s: 1.2

 [configuration] Using FileChangedReloadingStrategy for XMLConfiguration
 ---

 Key: CONFIGURATION-62
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-62
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: Windows 2000
 Platform: Other
Reporter: Raman
 Fix For: 1.2


 We are trying to use FileChangedReloadingStrategy for XMLConfiguration, but 
 its 
 not working. 
 We are using CompositeConfiguration and we have properties files as well as 
 some xml files. 
 I set FileChangedReloadingStrategy for all the configuration which is sub  
 class of FileConfiguration. But reloading is only working for properties.
 Code:
 
 Configuration config = null;
 ConfigurationFactory factory = new ConfigurationFactory();
 String configFile=c:/config.xml;
 factory.setConfigurationFileName(configFile);
 config = factory.getConfiguration();
 CompositeConfiguration cc=((CompositeConfiguration)config);
 int noOfConfig=cc.getNumberOfConfigurations();
 for(int i=0;inoOfConfig;i++){
 System.out.println(cc.getConfiguration(i).getClass() + :  + 
 (cc.getConfiguration(i)  instanceof  FileConfiguration));
 if((cc.getConfiguration(i)  instanceof  FileConfiguration)){
 ((FileConfiguration)cc.getConfiguration(i)).setReloadingStrategy(new 
 FileChangedReloadingStrategy());
 }
 Is it possible to use FileChangedReloadingStrategy for xmlconfiguration.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-63) [configuration] ConfigurationUtils.locate throws NullPointerException if the context ClassLoader is null


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-63:


Affects Version/s: (was: 1.2)
   1.3

 [configuration] ConfigurationUtils.locate throws NullPointerException if the 
 context ClassLoader is null
 

 Key: CONFIGURATION-63
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-63
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.3
 Environment: Operating System: Windows XP
 Platform: PC
Reporter: nomus

 Hello,
 When the locate method attempts to find resource location from the context 
 classpath 
 (lines 375-384 in ConfigurationUtils.java) it fails (on line 378) if the 
 context 
 ClassLoader cannot be retrieved for the current thread.
 I suppose this bug is quite difficult to reproduce. I came accross it when I 
 and a 
 colleague of mine were testing a Java API (kept in one jar) that is called 
 from C++ 
 application. In the static initializer of a Java class I used the next line 
 to load 
 settings:
 config = new 
 PropertiesConfiguration(ConfigurationUtils.locate(properties/routing.
 properties));
 It worked fine if the class was used from another Java class that was 
 normally loaded 
 by JVM (for example my tests passed). But when my Java classes were executed 
 by JVM 
 started from C++ application it resulted in the next exception:
 java.lang.NullPointerException
   at org.apache.commons.configuration.ConfigurationUtils.
 locate(ConfigurationUtils.java:378)
   at org.apache.commons.configuration.ConfigurationUtils.
 locate(ConfigurationUtils.java:255)
 ...
 It is obvious from the ConfigurationUtils code that loader variable got null 
 value 
 (line 377) for some reason so the next step threw the exception.
 I suppose this bug can be easily fixed (just to add an additional check if 
 loader is 
 not null).
 As a workaround I will try to call locate method with a given base parameter 
 (but it 
 needs to determine location of my jar so it is a kind of overheads though it 
 would 
 work I hope).
 Sorry for my English.
 Hope it is useful,
 Denis

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-64) [configuration] clearXmlProperty doesn't remove list properties completely


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-64:


Fix Version/s: 1.0

 [configuration] clearXmlProperty doesn't remove list properties completely
 --

 Key: CONFIGURATION-64
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-64
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: All
 Platform: All
Reporter: Emmanuel Bourg
 Fix For: 1.0

 Attachments: clear-property-2.txt, clear-property.txt, 
 clear-xml-property.diff


 clearXmlProperty in XMLConfiguration stops on the first element found and
 doesn't examine the whole tree, that means calling clearXmlProperty on a list
 property only remove the first element. For example, given the following
 configuration file:
 configuration
 keyvalue1/key
 keyvalue2/key
 /configuration
 calling conf.clearProperty(key) and saving the configuration will generate 
 the
 following file instead of an empty configuration:
 configuration
 keyvalue2/key
 /configuration

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-211) CommandLineConfiguration


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-211:
-

Attachment: CommandLineConfiguration.java

This is another implementation derived from my previous class :
- the remaining arguments are added to the configuration under the 
CommandLineConfiguration.PARAMETERS_KEY
- properties can be specified as -key=value and --key=value
- the value is optional, -key is considered as a boolean flag
- a no arg constructor is present, allowing a change of the list delimiter 
before parsing the arguments



 CommandLineConfiguration
 

 Key: CONFIGURATION-211
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-211
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: Nightly Builds
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 1.5

 Attachments: CLI-CommandLineConfiguration.java, 
 CommandLineConfiguration.java, CommandLineConfiguration.java, 
 TestCommandLineConfiguration.java


 I implemented a simple configuration taking the properties from the command
 line. I don't know if it is worth adding in the main code base, but I'm
 submitting it here if ever someone find it useful. Comments are welcome :)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (CONFIGURATION-267) INIConfiguration.save() doesn't save file correctly

2007-04-23 Thread Emmanuel Bourg (JIRA)


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg resolved CONFIGURATION-267.
--

   Resolution: Fixed
Fix Version/s: 1.5
 Assignee: Emmanuel Bourg

Thank you for reporting this issue, I fixed it.

 INIConfiguration.save() doesn't save file correctly
 ---

 Key: CONFIGURATION-267
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-267
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
 Environment: Windows XP SP2
Reporter: Zhenbang Wei
 Assigned To: Emmanuel Bourg
 Fix For: 1.5


 The PrintWriter used by save() method implemented in INIConfiguration is not 
 flushed so that configurations maybe not saved completely.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-262) Binary property list format

2007-04-23 Thread Emmanuel Bourg (JIRA)


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-262:
-

Priority: Minor  (was: Major)

 Binary property list format
 ---

 Key: CONFIGURATION-262
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-262
 Project: Commons Configuration
  Issue Type: New Feature
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 1.5

 Attachments: CFBinaryPList.c


 With OS X 10.4 Apple introduced a variant of the plist format that is 
 compressed using a binary format. That would be nice to support this format 
 with a BinaryPropertyListConfiguration class.
 I haven't found the specification of this format. 
 The plutil tool can be used to convert between xml and binary plist files.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-257) XMLConfiguration with Schema

2007-04-23 Thread Emmanuel Bourg (JIRA)


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490887
 ] 

Emmanuel Bourg commented on CONFIGURATION-257:
--

We could implement a setSchema(URL url, String language) method using 
reflection, and maybe a setSchema(Object) method accepting only a Schema 
instance.

Anyone has an example of schema that would help us building a test case ?

 XMLConfiguration with Schema
 

 Key: CONFIGURATION-257
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-257
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.3
 Environment: no special issues
Reporter: Andre Pietsch
Priority: Minor
 Fix For: 1.5


 It would be nice if you can set a self defined schema or better a schema file 
 to validate a XML-file that has no schema defined in its source.
 I would be happy with something like XMLConfiguratiom.setSchema(java.io.File 
 schemaFile) or XMLConfiguration.setSchema(javax.xml.validation.Schema schema) 
 that is forwarded to the XML-parser used by XMLConfiguration.
 Thanks alot...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [nightly build] configuration failed.

2007-04-22 Thread Emmanuel Bourg


Thank you Phil ! I applied the fix.

Emmanuel Bourg


Phil Steitz a écrit :

Looking at the old xdoc 1.8 jelly code, looks like what is failing
here is the report registration.  I don't know why exactly, but
upgrading the javadoc plugin to 1.8 works 4 me to fix this:

Index: project.xml
===
--- project.xml(revision 531127)
+++ project.xml(working copy)
@@ -502,6 +502,18 @@
  /comment
  /properties
/dependency
+dependency
+  groupIdmaven/groupId
+  artifactIdmaven-javadoc-plugin/artifactId
+  version1.8/version
+  urlhttp://maven.apache.org/maven-1.x/plugins/javadoc//url
+  typeplugin/type
+  properties
+  comment
+  lt;stronggt;Site Onlylt;/stronggt; - v1.8 (minimum)
+  /comment
+  /properties
+/dependency

  /dependencies

On 4/21/07, Phil Steitz [EMAIL PROTECTED] wrote:

Failed build logs:
http://vmbuild.apache.org/~commons/nightly/logs//20070421/configuration.log 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-3) Drop 1st class dependency on commons-logging

2007-04-22 Thread Emmanuel Bourg (JIRA)


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490758
 ] 

Emmanuel Bourg commented on CONFIGURATION-3:


It's still possible to use Log4J with the Java logging API, it's as simple as 
writing a custom Filter or Handler redirecting every log call to Log4J. I'm 
surprised Log4J doesn't provide such a bridge by default. I have found one 
example of a Filter doing this :

http://www.fedora.info/download/2.2/javadocs/fedora/utilities/Log4JRedirectFilter.html


 Drop 1st class dependency on commons-logging
 

 Key: CONFIGURATION-3
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-3
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.2
Reporter: Joerg Schaible
Priority: Minor
 Fix For: 2.0


 Currently commons-logging is reported as first class dependency in the project
 reports. This is not true. The only classes that make direct usage of JCL are
 ConfigurationDynaBean/Class and this only for tracing. It would be nice to
 eliminate this reference at all and list JCL only as transitive dependency of
 digester and beanutils.
 We might support logging with the monitor/listener concept of
 http://issues.apache.org/bugzilla/show_bug.cgi?id=38929

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[configuration] Roadmap

2007-04-19 Thread Emmanuel Bourg

Hi, I was thinking lately about the orientation for the next releases. I 
focused on the design choices, some features like new configurations 
could be added at any moment. Here is what we could do, feel free to add 
your points to the list.



Commons Configuration 1.5.x

Java 1.3 compatible
Deprecate everything to be removed in 2.x
Backport of bug fixes until Configuration 3 is out


Commons Configuration 2.x

Java 1.4 compatible
API cleanup, but no major refactoring
Remove the deprecated methods and classes (HierarchicalXMLConfiguration, 
ConfigurationFactory ?)

Remove the dependency on Commons Logging
PreferencesConfiguration, ConfigurationPreferences
Implement the Locators ?
Add the generic get methods to the Configuration interface
Backport of bug fixes after the release of Configuration 3


Commons Configuration 3.x

Java 5 compatible
New package : org.apache.commons.config
Remove the dependency on Commons Collections
In deepth refactoring of the API
Make all configurations hierarchical by default
Nodes are Configurations, like java.util.Preferences
Generification of the API
Pluggable converters (Morph, Beanutils ?)


Emmanuel Bourg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [configuration] Roadmap

2007-04-19 Thread Emmanuel Bourg


Jörg Schaible a écrit :

Hi Emmanuel,

do you think 2.x is worth it simply because of dropping JDK 1.3? You might 
still introduce Preferences in JCC 1.x - it is simply not usable in JDK 1.3.


I think 2.x is worth not only for dropping the Java 1.3 requirement, but 
also to introduce minor binary incompatible changes (new methods in the 
Configuration interface and removal of deprecated code for example).


Emmanuel Bourg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [configuration] Roadmap

2007-04-19 Thread Emmanuel Bourg


nicolas de loof a écrit :

I agrea with Jörg : having some classes depend on java 1.4 should not make
all the lib depend on java 1.4 when possible. This can be handled in maven2
with some compiler configuration (two executions with includes/excludes),
just by having some naming convention (or deticated package) for java
1.4classes.


I'm a bit reluctant to rely on Maven to manage a mixed build correctly. 
We have test cases that don't run on Java 1.3 for classes that do work 
on Java 1.3, it's getting weird.


I feel it'll be easier to manage 2 branches than fine tuning Maven to 
build both Java 1.3 and Java 1.4 versions.


Emmanuel Bourg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Commons Configuration] using setProperty for data element on XML plist

2007-04-19 Thread Emmanuel Bourg


Oliver Heger a écrit :

I haven't used XMLPropertyListConfiguration myself. But from a short 
glance at the code I fear that there could be a bug related to the 
handling of arrays. What exactly is the result when you call 
setProperty() with the modified byte[]?


I reproduced this issue, a byte[] is transformed into a list of integers 
by HierarchicalConfiguration.setProperty(). This code :


FileConfiguration config = new XMLPropertyListConfiguration();
config.setProperty(foo, new byte[] { 1, 2, 3, 4 });
config.save(config.plist);

generates this :

plist version=1.0
dict
keyfoo/key
integer1/integer

keyfoo/key
integer2/integer

keyfoo/key
integer3/integer

keyfoo/key
integer4/integer
/dict
/plist

instead of

plist version=1.0
dict
keyfoo/key
data01020304/data
/dict
/plist

I don't know how to fix this easily. Maybe by adding a flag in 
HierarchicalConfiguration to prevent the arrays from being split into a 
list of nodes ?


Emmanuel Bourg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Commons Configuration] using setProperty for data element on XML plist

2007-04-19 Thread Emmanuel Bourg


Oliver Heger a écrit :

I haven't used XMLPropertyListConfiguration myself. But from a short 
glance at the code I fear that there could be a bug related to the 
handling of arrays. What exactly is the result when you call 
setProperty() with the modified byte[]?


I commited a fix for this bug, it affected both plist configurations.

Oliver could you review my change please ? I'm not familiar with the new 
event notification stuff, I don't know if the right events are fired 
with this fix.


Emmanuel Bourg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Commons Configuration] using setProperty for data element on XML plist

2007-04-19 Thread Emmanuel Bourg


Oliver Heger a écrit :

Okay, I will have a look and write test cases for the events. From a 
first glance it seems that CLEAR_PROPERTY and AND_PROPERTY events are 
thrown instead of a SET_PROPERTY event.


Thank you. Is there a mechanism to disable the clear and add events ?


I haven't looked into this issue in detail, but wouldn't the 
addProperty() methods be affected, too?


I think so, I haven't tested this case yet.

Emmanuel Bourg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [configuration] Re: [nightly build] configuration failed.

2007-04-18 Thread Emmanuel Bourg

I did a fresh install of Maven 1.0.2 on people.apache.org (FreeBSD 6.1, 
Java 5u7), with a fresh checkout of the code, and ran 'maven site'. The 
build failed on checkstyle with this error :


Unable to create a Checker: cannot initialize module TreeWalker - 
Property 'allowMissingJavadoc' in module JavadocMethod does not exist, 
please check the documentation


I had the same issue on my laptop, this property exists in the 
checkstyle documentation though. I removed the offending line and 
restarted the site generation, it completed normally.


Now I wonder why Phil's nightly builds report an xdoc error and not the 
checkstyle error. What command is used to start the nightly build ?


Emmanuel Bourg




Emmanuel Bourg a écrit :
I have the same version of Maven and the build works fine with the xdoc 
plugin 1.8. What is wrong ?


Emmanuel Bourg


Phil Steitz a écrit :

Failed build logs:
http://vmbuild.apache.org/~commons/nightly/logs//20070415/configuration.log 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [configuration] Re: [nightly build] configuration failed.

2007-04-18 Thread Emmanuel Bourg


Oliver Heger a écrit :

I added an explicit dependency to the newest version of the checkstyle 
plugin to project.xml. This should solve the problem with checkstyle.


Thank you Oliver and Niall, it does indeed fix this issue.


For the other problem I agree with Nial's answer: Obviously the lower 
version of the xdoc plugin causes more problems than it solves. So we 
should better go with the current version, especially if this is the 
standard for most of the commons components.


That's the easy solution I agree, I don't want to waste too much time 
getting the titles right if Maven impose its own standard.


But I'm concerned about our nightly reports sending false positives 
(xdoc) and missing real issues (checkstyle). Maybe it's time to 
reinstall Maven for the nightly builds, or is this too much trouble ?



Now the new dependency to javax.mail causes me trouble: Compiling with 
JDK 1.3 fails now because the compiler reports an invalid class version. 
The mail jar has been compiled with a JDK  1.3. So what do we do?


I'll check if we can use a previous version of javamail compatible with 
Java 1.3.



In general I wonder whether all these specialized get methods make sense 
for DataConfiguration. Wouldn't it be better and more flexible to have a 
generic method


Object getProperty(String key, Class targetClass)

and then provide a means for registering arbitrary converters? We could 
indeed use the Beanutils converters for this purpose as was suggested by 
one jira ticket.


Actually we have the generic methods ! :) I didn't add more specialized 
get methods in DataConfiguration for the new types, instead I introduced 
generic getters :


get(Class cls, String key)

getArray(Class cls, String key)

getList(Class cls, String key)


The specialized getters now call the generic getters (except for Date 
and Calendar), this cuts the nloc by a half. It might be worth moving 
these methods into AbstractConfiguration now, they offer the features of 
DataConfiguration without the horde of methods. They would be a nice 
addition to the Configuration interface for the next major release too.


Regarding the converters I believe we'll probably delegate this part to 
another API sooner or later (Morph, Beanutils...), but I don't want to 
add another core dependency. I was thinking about a pluggable conversion 
system, we would provide a basic implementation derived from the current 
code in PropertyConverter, and if someone wants more complex conversions 
he could plug a custom converter using another API.


Emmanuel Bourg







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [configuration] Re: [nightly build] configuration failed.

2007-04-18 Thread Emmanuel Bourg

Now the new dependency to javax.mail causes me trouble: Compiling with 
JDK 1.3 fails now because the compiler reports an invalid class 
version. The mail jar has been compiled with a JDK  1.3. So what do 
we do?


I'll check if we can use a previous version of javamail compatible with 
Java 1.3.


I haven't found a version easily usable by Maven that is compatible with 
Java 1.3. The Geronimo jars were compiled with Java 1.4.


We can either use javamail 1.3.3 from Sun (i.e more complex build 
instructions) or change the test case to use reflection (it will fail, 
but at least it compiles).


Emmanuel Bourg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [configuration] Re: [nightly build] configuration failed.

2007-04-18 Thread Emmanuel Bourg

I changed TestDataConfiguration using reflection, let me know how it 
works for you. The tests with InternetAddress are skipped on Java 1.3.


Emmanuel Bourg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [configuration] Re: [nightly build] configuration failed.

2007-04-16 Thread Emmanuel Bourg


Phil Steitz a écrit :

On 4/15/07, Emmanuel Bourg [EMAIL PROTECTED] wrote:

I have the same version of Maven and the build works fine with the xdoc
plugin 1.8. What is wrong ?


Here is what I get from maven clean xdoc on vmbuild for configuration:

File.. /home/psteitz/.maven/cache/maven-xdoc-plugin-1.8/plugin.jelly
Element... attainGoal
Line.. 687
Column 48
No goal [xdoc:init-i18n]

It is using the 1.8 version of the xdoc plugin.  Are you using maven
1.0.2, or maven 1.1?


I have Maven 1.0.2 on Windows, with the xdoc 1.8 plugin in the Maven 
plugins directory. I downgraded the version of this plugin in the 
project.xml file from 1.9.2 to 1.8 to change the way the titles of the 
pages are generated.


Could this be an issue with the Maven cache ?

Emmanuel Bourg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-249) save to URLs with a protocol other than file:


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489044
 ] 

Emmanuel Bourg commented on CONFIGURATION-249:
--

Thank you Anselm, I'll try to build a test case with a FTP server.

 save to URLs with a protocol other than file:
 ---

 Key: CONFIGURATION-249
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-249
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.4
Reporter: Anselm Kruis
Priority: Minor
 Fix For: 1.5


 Currently, the save(URL) method from AbstractFileConfiguration only supports 
 file: URLs. 
 Why not support  writing to URLs too? It is as simple like this
   java.net.URLConnection connection = 
 url.openConnection();
   connection.setDoOutput(true);
   connection.setDoInput(false);
   save(connection.getOutputStream());
 I could prepare a patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-249) save to URLs with a protocol other than file:


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489073
 ] 

Emmanuel Bourg commented on CONFIGURATION-249:
--

I changed AbstractFileConfiguration.save(URL) to allow  non file URLs, could 
you give it a try Anselm ? It worked fine with a FTP server, I have still to 
build a test case demonstrating this. For HTTP URLs I had to force the PUT 
method since the POST method is used by default once setDoOutput(true) is 
called. I haven't tested with a http server allowing PUT requests yet.

 save to URLs with a protocol other than file:
 ---

 Key: CONFIGURATION-249
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-249
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.4
Reporter: Anselm Kruis
Priority: Minor
 Fix For: 1.5


 Currently, the save(URL) method from AbstractFileConfiguration only supports 
 file: URLs. 
 Why not support  writing to URLs too? It is as simple like this
   java.net.URLConnection connection = 
 url.openConnection();
   connection.setDoOutput(true);
   connection.setDoInput(false);
   save(connection.getOutputStream());
 I could prepare a patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-3) [configuration] Drop 1st class dependency on commons-logging


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489130
 ] 

Emmanuel Bourg commented on CONFIGURATION-3:


I'd like to reopen this request, but schedule it for the next major release 
(2.0). Reducing the dependencies is desirable to simplify the usage of the 
library, commons logging could be replaced by the java.util logging API when we 
give up the Java 1.3 requirement.

 [configuration] Drop 1st class dependency on commons-logging
 

 Key: CONFIGURATION-3
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-3
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.2
 Environment: Operating System: All
 Platform: Other
Reporter: Joerg Schaible
Priority: Minor

 Currently commons-logging is reported as first class dependency in the project
 reports. This is not true. The only classes that make direct usage of JCL are
 ConfigurationDynaBean/Class and this only for tracing. It would be nice to
 eliminate this reference at all and list JCL only as transitive dependency of
 digester and beanutils.
 We might support logging with the monitor/listener concept of
 http://issues.apache.org/bugzilla/show_bug.cgi?id=38929

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (CONFIGURATION-3) [configuration] Drop 1st class dependency on commons-logging


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg reopened CONFIGURATION-3:



 [configuration] Drop 1st class dependency on commons-logging
 

 Key: CONFIGURATION-3
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-3
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.2
 Environment: Operating System: All
 Platform: Other
Reporter: Joerg Schaible
Priority: Minor

 Currently commons-logging is reported as first class dependency in the project
 reports. This is not true. The only classes that make direct usage of JCL are
 ConfigurationDynaBean/Class and this only for tracing. It would be nice to
 eliminate this reference at all and list JCL only as transitive dependency of
 digester and beanutils.
 We might support logging with the monitor/listener concept of
 http://issues.apache.org/bugzilla/show_bug.cgi?id=38929

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-3) Drop 1st class dependency on commons-logging


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-3:
---

Fix Version/s: 2.0
   Issue Type: Improvement  (was: Bug)
  Environment: (was: Operating System: All
Platform: Other)
  Summary: Drop 1st class dependency on commons-logging  (was: 
[configuration] Drop 1st class dependency on commons-logging)

 Drop 1st class dependency on commons-logging
 

 Key: CONFIGURATION-3
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-3
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.2
Reporter: Joerg Schaible
Priority: Minor
 Fix For: 2.0


 Currently commons-logging is reported as first class dependency in the project
 reports. This is not true. The only classes that make direct usage of JCL are
 ConfigurationDynaBean/Class and this only for tracing. It would be nice to
 eliminate this reference at all and list JCL only as transitive dependency of
 digester and beanutils.
 We might support logging with the monitor/listener concept of
 http://issues.apache.org/bugzilla/show_bug.cgi?id=38929

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r529210 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/DatabaseConfiguration.java test/org/apache/commons/configuration/TestDatabaseConfigu

2007-04-16 Thread Emmanuel Bourg


Oliver Heger a écrit :
I fear, making getConnection() package private is a binary incompatible 
change. So please revert this change.


This change is not binary compatible indeed, but the method was 
protected, just introduced in configuration 1.4, and unlikely to be used 
by anyone (getDatasource().getConnection() is preferable to get a 
connection). I wish I could have seen this before the release, I'd like 
to keep the API as clean as possible and prevent unnecessary classes and 
methods in the javadocs, otherwise it's confusing for the users.




+1 for the enhanced documentation!


I'm still catching up on the unread mails of the dev list, someone 
complained about the lack of documentation for DatabaseConfiguration so 
I wrote the javadoc. An entry in the userguide would be nice too.


Emmanuel Bourg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r529210 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/DatabaseConfiguration.java test/org/apache/commons/configuration/TestDatabaseConfigu

2007-04-16 Thread Emmanuel Bourg


Oliver Heger a écrit :


Sorry, but our rules for releases are quite clear: no binary 
incompatible changes in a minor release. We can hide or remove this 
method in the 2.0 release, but not in a 1.x release.


BTW it might be useful for a sub class to have an opportunity to hook 
into the mechanism of obtaining a connection.


It's still possible to hook the connection used by the configuration by 
providing a custom Datasource, actually that's the purpose of a Datasource.


I'll revert the change but mark the method as deprecated.

Emmanuel Bourg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (LANG-328) LocaleUtils.toLocale() rejects strings with only language+variant

LocaleUtils.toLocale() rejects strings with only language+variant
-

 Key: LANG-328
 URL: https://issues.apache.org/jira/browse/LANG-328
 Project: Commons Lang
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Emmanuel Bourg


LocaleUtils.toLocale() throws an exception on strings containing a language and 
a variant but no country code. For example : fr__POSIX

This string can be produced with the JDK by instanciating a Locale with an 
empty string for the country : new Locale(fr, , POSIX).toString(). 
According to the javadoc for the Locale class a variant is allowed with just a 
language code or just a country code.

Commons Configuration handles this case in its PropertyConverter.toLocale() 
method. I'd like to replace our implementation by the one provided by 
LocaleUtils, but our tests fail due to this case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [configuration] 1.4 dependency in PropertyListParser.java

2007-04-15 Thread Emmanuel Bourg


Oliver Heger a écrit :

I agree with using Java 5 for version 2.0. About switching to JDK 1.4 I 
am not sure. I think we should do this switch as late as possible. I.e. 
as long as no specific 1.4 features are needed for the fixes and 
features we implement, we should stay with 1.3.


I remember a posting on this list shortly before the Configuration 1.3 
release, in which the author made clear that he still needs JDK 1.3 
support.


On the other hand there are people requesting features that will require 
Java 1.4 like the Preferences integration. I see 2 solutions to satisfy 
everyone:


1. release a last Java 1.3 version and support it as long as possible by 
backporting the bug fixes. That may be a 1.4.x branch.


2. implement the new classes with Java 1.4 but keep the existing code 
compatible with Java 1.3. The build may be difficult to manage with this 
mixed approach, we will need 2 compilation procedures, one with the JDK 
1.3 excluding the new classes, and one with the JDK 1.4 with all classes.


One of my hopes on moving to Java 1.4 is to remove the core dependency 
on [collections]. We need it mainly for the LinkedMap and the 
ListOrderedSet, instead of these classes we could use the Java 1.4 
alternatives. The other usages of [collections] are less critical and 
could be implemented differently. Removing this dependency will not be 
possible with the second solution though.


Emmanuel Bourg





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[configuration] Re: [nightly build] configuration failed.

2007-04-15 Thread Emmanuel Bourg

I have the same version of Maven and the build works fine with the xdoc 
plugin 1.8. What is wrong ?


Emmanuel Bourg


Phil Steitz a écrit :

Failed build logs:
http://vmbuild.apache.org/~commons/nightly/logs//20070415/configuration.log

-
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]

Re: [configuration] 1.4 dependency in PropertyListParser.java

2007-04-13 Thread Emmanuel Bourg


My bad sorry, I'll fix this.

This might be the opportunity to discuss the JRE requirement for the 
next releases. What version do we use (1.4 or 5) and when ? I believe 
it's too early to go directly to Java 5, on the server side JEE 5 is not 
widely adopted yet (BEA just released WebLogic 10), and on the client 
side there are still a lot of OS X users that haven't upgraded to Tiger 
(10.4).


I would suggest moving to Java 1.4 for a release in the near future 
(configuration 1.5 or 1.6) and then jump to Java 5 for the next major 
release (2.0) involving a deep refactoring of the component.


Even with a version requiring Java 5, I think we should still support 
the latest pre Java 5 version by fixing the major bugs reported. Thus we 
will not force people to upgrade, there will still be a great version 
compatible with Java 1.3/1.4 around, and people with Java 5 will enjoy 
an even better version.


Emmanuel Bourg



Oliver Heger a écrit :
The latest commit [1] introduced a dependency to JDK 1.4: The 
initCause() method of Exception is not available in JDK 1.3. (I found 
this because I use to compile with JDK 1.3 by default and got two 
compile errors.)


Oliver

[1]
r527436 | ebourg | 2007-04-11 11:57:29 +0200 (Mi, 11 Apr 2007) | 1 line

Implemented the GNUStep extension for plist files to specify date bjects 
(CONFIGURATION-261)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-258) JSON configuration


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488762
 ] 

Emmanuel Bourg commented on CONFIGURATION-258:
--

The parser should be easy to write with JavaCC, but is JSON really used for 
configuration files ? I thought it was mainly an object serialization format 
used for AJAX applications.

 JSON configuration
 --

 Key: CONFIGURATION-258
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.3
 Environment:  
 « Hide
 Operating System: All
 Platform: All
Reporter: Antonio López-Cerón Vivo
Priority: Minor
 Fix For: 1.5


 JSON  is a lightweight data-interchange format
 {menu: {
   id: file,
   value: File,
   popup: {
 menuitem: [
   {value: New, onclick: CreateNewDoc()},
   {value: Open, onclick: OpenDoc()},
   {value: Close, onclick: CloseDoc()}
 ]
   }
 }}
 All references can be located at
 http://www.json.org/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-262) Binary property list format


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-262:
-

Attachment: CFBinaryPList.c

Binary plist parser from the Open Darwin project :

http://darwinsource.opendarwin.org/10.3/CF-299/Parsing.subproj/CFBinaryPList.c

It details the structure of a binary plist file.



 Binary property list format
 ---

 Key: CONFIGURATION-262
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-262
 Project: Commons Configuration
  Issue Type: New Feature
Reporter: Emmanuel Bourg
 Fix For: 1.5

 Attachments: CFBinaryPList.c


 With OS X 10.4 Apple introduced a variant of the plist format that is 
 compressed using a binary format. That would be nice to support this format 
 with a BinaryPropertyListConfiguration class.
 I haven't found the specification of this format. 
 The plutil tool can be used to convert between xml and binary plist files.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-180) Cache DatabaseConfiguration values for higher performance


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488794
 ] 

Emmanuel Bourg commented on CONFIGURATION-180:
--

I modified DatabaseConfiguration to ensure the connection is always closed.

 Cache DatabaseConfiguration values for higher performance
 -

 Key: CONFIGURATION-180
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-180
 Project: Commons Configuration
  Issue Type: Improvement
Reporter: Stephen Cooper
Priority: Minor
 Fix For: 1.5

 Attachments: dbpreload.txt, Enhancement33553.checkstyle.patch, 
 Enhancement33553.patch


 The DatabaseConfiguration class queries each property as it gets the request 
 for each property.  This is 
 nice for ensuring that you're always up to date, but it doesn't give very 
 good performance in enterprise 
 applications, where the database may not be on the same subnet.
 What we need is the ability to hit the database once, get all the keys/values 
 and then serve up 
 getString etc. from that cache.
 I'll be opening a separate enhancement to have a generic Reloading Strategy 
 which could then be 
 applied to this caching DatabaseConfiguration approach.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-136) Reloading may corrupt the configuration


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488813
 ] 

Emmanuel Bourg commented on CONFIGURATION-136:
--

The copy of the store can be avoided by keeping a reference to the previous 
store and creating a new empty store before loading the file :

Map previousStore = store;
store = new LinkedMap();

However this will only work for the flat configurations like 
PropertiesConfiguration and INIConfiguration, the hierarchical configurations 
like XMLConfiguration don't use the Map in BaseConfiguration to store the 
properties.

 Reloading may corrupt the configuration
 ---

 Key: CONFIGURATION-136
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-136
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
Reporter: nicolas de loof
 Fix For: 1.5


 Current reloading process clears current properties and load updated values 
 from
 resource reader. If an IO error occurs (or invalid format), the configuration
 gets corrupted and the application becomes unstable.
 It may be better for hot-reload to put loaded values into a temporary 
 Properties
 and replace previous values only when reloading is successful. 
 It may also allow to use a 'currentlty-reloading' flag in the synchronized
 'reload' block to avoid blocking threads during a reload (they could access
 safelly the 'old' properties until reload is finished)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CONFIGURATION-249) save to URLs with a protocol other than file:


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488818
 ] 

Emmanuel Bourg commented on CONFIGURATION-249:
--

Just curious, why do you want to save to a non file URL ? To write the 
configuration on a FTP server ?

 save to URLs with a protocol other than file:
 ---

 Key: CONFIGURATION-249
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-249
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.4
Reporter: Anselm Kruis
Priority: Minor
 Fix For: 1.5


 Currently, the save(URL) method from AbstractFileConfiguration only supports 
 file: URLs. 
 Why not support  writing to URLs too? It is as simple like this
   java.net.URLConnection connection = 
 url.openConnection();
   connection.setDoOutput(true);
   connection.setDoInput(false);
   save(connection.getOutputStream());
 I could prepare a patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (CONFIGURATION-261) Add support for date objects in PropertyListConfiguration

2007-04-11 Thread Emmanuel Bourg (JIRA)


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg resolved CONFIGURATION-261.
--

Resolution: Fixed

Feature implemented and checked in.

 Add support for date objects in PropertyListConfiguration
 -

 Key: CONFIGURATION-261
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-261
 Project: Commons Configuration
  Issue Type: Improvement
Reporter: Emmanuel Bourg
 Fix For: 1.5


 PropertyListConfiguration could implement the GNUStep extension for the 
 property list format to support date objects. A date is formatted like this :
 *D2002-03-22 11:30:00 +0100
 See 
 http://www.gnustep.org/resources/documentation/Developer/Base/Reference/NSPropertyList.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (CONFIGURATION-260) Incorrect date format in XMLPropertyListConfiguration

Incorrect date format in XMLPropertyListConfiguration
-

 Key: CONFIGURATION-260
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-260
 Project: Commons Configuration
  Issue Type: Bug
Reporter: Emmanuel Bourg
 Fix For: 1.5


The date format used in XMLPropertyListConfiguration is incorrect, it should be 
:

date2002-03-22 11:30:00 +0100/date

instead of :

date2005-01-01T12:00:00-0700/date

See 
http://www.gnustep.org/resources/documentation/Developer/Base/Reference/NSPropertyList.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (CONFIGURATION-261) Add support for date objects in PropertyListConfiguration

Add support for date objects in PropertyListConfiguration
-

 Key: CONFIGURATION-261
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-261
 Project: Commons Configuration
  Issue Type: Improvement
Reporter: Emmanuel Bourg
 Fix For: 1.5


PropertyListConfiguration could implement the GNUStep extension for the 
property list format to support date objects. A date is formatted like this :

*D2002-03-22 11:30:00 +0100

See 
http://www.gnustep.org/resources/documentation/Developer/Base/Reference/NSPropertyList.html


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (CONFIGURATION-50) [configuration] FileChangedReloadingStrategy fails to properly detect file change


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg closed CONFIGURATION-50.
---


 [configuration] FileChangedReloadingStrategy fails to properly detect file 
 change
 -

 Key: CONFIGURATION-50
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-50
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: Windows XP
 Platform: Other
Reporter: Eric Lee
 Attachments: ConfigurationChangedReloadingStrategy.java, 
 ConfigurationUtils.java.patch, patch.diff, patch.diff


 Two code examples that fail to detect / load file changes:
 =Sample
 1:  If properties file location is determined by searching the classpath,
 changes are not detected.
 try {
 PropertiesConfiguration propConfig = new
 PropertiesConfiguration(commons.properties);
 FileChangedReloadingStrategy strategy = new FileChangedReloadingStrategy();
 strategy.setConfiguration(propConfig);
 strategy.setRefreshDelay(500);
 strategy.init();
 for (;;){
 String prop1 = propConfig.getString(prop1);
 System.out.println(Calendar.getInstance().getTime() +  :  +
 strategy.reloadingRequired() +  :  + prop1);
 Thread.sleep(1000);
 }
 } catch (Throwable t){
 t.printStackTrace();
 }
 =
 Sample 2:  If properties file location is specified, changes are not detected
 but not loaded.
 try {
 PropertiesConfiguration propConfig = new
 PropertiesConfiguration(d:/tmp/commons.properties);
 FileChangedReloadingStrategy strategy = new FileChangedReloadingStrategy();
 strategy.setConfiguration(propConfig);
 strategy.setRefreshDelay(500);
 strategy.init();
 for (;;){
 String prop1 = propConfig.getString(prop1);
 System.out.println(Calendar.getInstance().getTime() +  :  +
 strategy.reloadingRequired() +  :  + prop1);
 Thread.sleep(1000);
 }
 } catch (Throwable t){
 t.printStackTrace();
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (CONFIGURATION-50) [configuration] FileChangedReloadingStrategy fails to properly detect file change


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg reopened CONFIGURATION-50:
-


 [configuration] FileChangedReloadingStrategy fails to properly detect file 
 change
 -

 Key: CONFIGURATION-50
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-50
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: Windows XP
 Platform: Other
Reporter: Eric Lee
 Attachments: ConfigurationChangedReloadingStrategy.java, 
 ConfigurationUtils.java.patch, patch.diff, patch.diff


 Two code examples that fail to detect / load file changes:
 =Sample
 1:  If properties file location is determined by searching the classpath,
 changes are not detected.
 try {
 PropertiesConfiguration propConfig = new
 PropertiesConfiguration(commons.properties);
 FileChangedReloadingStrategy strategy = new FileChangedReloadingStrategy();
 strategy.setConfiguration(propConfig);
 strategy.setRefreshDelay(500);
 strategy.init();
 for (;;){
 String prop1 = propConfig.getString(prop1);
 System.out.println(Calendar.getInstance().getTime() +  :  +
 strategy.reloadingRequired() +  :  + prop1);
 Thread.sleep(1000);
 }
 } catch (Throwable t){
 t.printStackTrace();
 }
 =
 Sample 2:  If properties file location is specified, changes are not detected
 but not loaded.
 try {
 PropertiesConfiguration propConfig = new
 PropertiesConfiguration(d:/tmp/commons.properties);
 FileChangedReloadingStrategy strategy = new FileChangedReloadingStrategy();
 strategy.setConfiguration(propConfig);
 strategy.setRefreshDelay(500);
 strategy.init();
 for (;;){
 String prop1 = propConfig.getString(prop1);
 System.out.println(Calendar.getInstance().getTime() +  :  +
 strategy.reloadingRequired() +  :  + prop1);
 Thread.sleep(1000);
 }
 } catch (Throwable t){
 t.printStackTrace();
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (CONFIGURATION-50) [configuration] FileChangedReloadingStrategy fails to properly detect file change


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg resolved CONFIGURATION-50.
-

Resolution: Fixed

 [configuration] FileChangedReloadingStrategy fails to properly detect file 
 change
 -

 Key: CONFIGURATION-50
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-50
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: Windows XP
 Platform: Other
Reporter: Eric Lee
 Attachments: ConfigurationChangedReloadingStrategy.java, 
 ConfigurationUtils.java.patch, patch.diff, patch.diff


 Two code examples that fail to detect / load file changes:
 =Sample
 1:  If properties file location is determined by searching the classpath,
 changes are not detected.
 try {
 PropertiesConfiguration propConfig = new
 PropertiesConfiguration(commons.properties);
 FileChangedReloadingStrategy strategy = new FileChangedReloadingStrategy();
 strategy.setConfiguration(propConfig);
 strategy.setRefreshDelay(500);
 strategy.init();
 for (;;){
 String prop1 = propConfig.getString(prop1);
 System.out.println(Calendar.getInstance().getTime() +  :  +
 strategy.reloadingRequired() +  :  + prop1);
 Thread.sleep(1000);
 }
 } catch (Throwable t){
 t.printStackTrace();
 }
 =
 Sample 2:  If properties file location is specified, changes are not detected
 but not loaded.
 try {
 PropertiesConfiguration propConfig = new
 PropertiesConfiguration(d:/tmp/commons.properties);
 FileChangedReloadingStrategy strategy = new FileChangedReloadingStrategy();
 strategy.setConfiguration(propConfig);
 strategy.setRefreshDelay(500);
 strategy.init();
 for (;;){
 String prop1 = propConfig.getString(prop1);
 System.out.println(Calendar.getInstance().getTime() +  :  +
 strategy.reloadingRequired() +  :  + prop1);
 Thread.sleep(1000);
 }
 } catch (Throwable t){
 t.printStackTrace();
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (CONFIGURATION-167) [configuration] Versioned Javadocs


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg reopened CONFIGURATION-167:
--


 [configuration] Versioned Javadocs
 --

 Key: CONFIGURATION-167
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-167
 Project: Commons Configuration
  Issue Type: Improvement
 Environment: Operating System: All
 Platform: All
Reporter: Roger Glover
Priority: Minor

 The value of the javadocs for commons-configuration on the public web site 
 (http://jakarta.apache.org/commons/configuration/apidocs) is greatly 
 diminished 
 by the fact that they do not match the latest public release (1.0, according 
 to 
 iBiblio). In particular, the javadocs reference a MapConfiguration class that 
 is not in the latest released jar (1.0). It is very frustrating to find 
 exactly 
 what you need in the documentation, only to discover that it is not yet in 
 the 
 actual code. It also rattles my already shaky confidence in the quality of 
 the 
 documentation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (CONFIGURATION-167) [configuration] Versioned Javadocs


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg resolved CONFIGURATION-167.
--

   Resolution: Fixed
Fix Version/s: 1.2

 [configuration] Versioned Javadocs
 --

 Key: CONFIGURATION-167
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-167
 Project: Commons Configuration
  Issue Type: Improvement
 Environment: Operating System: All
 Platform: All
Reporter: Roger Glover
Priority: Minor
 Fix For: 1.2


 The value of the javadocs for commons-configuration on the public web site 
 (http://jakarta.apache.org/commons/configuration/apidocs) is greatly 
 diminished 
 by the fact that they do not match the latest public release (1.0, according 
 to 
 iBiblio). In particular, the javadocs reference a MapConfiguration class that 
 is not in the latest released jar (1.0). It is very frustrating to find 
 exactly 
 what you need in the documentation, only to discover that it is not yet in 
 the 
 actual code. It also rattles my already shaky confidence in the quality of 
 the 
 documentation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (CONFIGURATION-262) Binary property list format

Binary property list format
---

 Key: CONFIGURATION-262
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-262
 Project: Commons Configuration
  Issue Type: New Feature
Reporter: Emmanuel Bourg
 Fix For: 1.5


With OS X 10.4 Apple introduced a variant of the plist format that is 
compressed using a binary format. That would be nice to support this format 
with a BinaryPropertyListConfiguration class.

I haven't found the specification of this format. 

The plutil tool can be used to convert between xml and binary plist files.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (CONFIGURATION-168) [configuration] Messed file on saving an XMLConfiguration