[jira] Resolved: (CONFIGURATION-143) [configuration] Support event listeners for configurations
[ https://issues.apache.org/jira/browse/CONFIGURATION-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-143. Resolution: Fixed Fix Version/s: 1.4 Basic event support (i.e. the raw event layer) was added a while ago. I would like to close this ticket. For enhanced requirements (e.g. filtering of events) further tickets can be opened. [configuration] Support event listeners for configurations -- Key: CONFIGURATION-143 URL: https://issues.apache.org/jira/browse/CONFIGURATION-143 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.2 Final Environment: Operating System: other Platform: Other Reporter: Oliver Heger Priority: Minor Fix For: 1.4 Attachments: events-tests.diff, events.diff, events.diff I would like to suggest creating a ConfigurationEvent class and a ConfigurationEventListener interface for monitoring changes on configurations. AbstractConfiguration could act as an event source allowing listeners to register itself at an instance. Whenever this instance is modified a notification is sent out to all registered listeners. The event class could contain - a reference to the affected Configuration object - an ID about the type of the event (e.g. property added, property removed, configuration cleared etc.) - the name of the affected property if applicable - the value of the affected property if applicable The listener interface could be quite simple and contain only a single method: void configurationChanged(ConfigurationEvent event); While an implementation should not be too complicated some details need to be cleared: - ATM as AbstractConfiguration is implemented an operation could cause multiple events. For instance setProperty() is implemented as calling clearProperty() and then addProperty(). Should this be caught and treated as a single event? - Should a reload of a file based configuration cause an event? Could this be problematic if a called listener tries to access the configuration? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-165) [configuration] Use beanutils for conversions
[ https://issues.apache.org/jira/browse/CONFIGURATION-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-165. Resolution: Won't Fix This issue is now open for a long while. ATM I see no really benefit in changing the conversion code to use beanutils. The additional dependency may even be considered as harmful by some people. Maybe if the converters in beanutils are enhanced to cover all the use cases we need, or if the [convert] project wakes up again, we can re-evaluate this issue. So closing this ticket as won't fix. [configuration] Use beanutils for conversions - Key: CONFIGURATION-165 URL: https://issues.apache.org/jira/browse/CONFIGURATION-165 Project: Commons Configuration Issue Type: Improvement Environment: Operating System: other Platform: Other Reporter: Ittay Dror Priority: Minor Currently AbstractConfiguration has its own logic for conversion. This makes it non standard with commons beanutils. Furthermore, commons beanutils is extendible, so by using it, one can write a method Object getProperty(String key, Class c) which would automatically convert the returned value of getProperty(String key) to the requested class. This means that (as long as I register the right converter) i can use getProperty(my.class, MyClass.class) and get automatically and instance of MyClass. Very usefull, esp. for enumerations (which can easily have their own converter if using commons-lang's enum) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-215) Using relative URLs
[
https://issues.apache.org/jira/browse/CONFIGURATION-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463705
]
Oliver Heger commented on CONFIGURATION-215:
I never got a response to my last suggestions. What is the current status of
this issue? Is this feature still needed?
Using relative URLs
---
Key: CONFIGURATION-215
URL: https://issues.apache.org/jira/browse/CONFIGURATION-215
Project: Commons Configuration
Issue Type: Improvement
Reporter: Michiel Kalkman
Priority: Minor
It would be useful to be able to specify URLs in configuration item values
that are relative to the configuration.
A sample. I have the following files.
A/config.xml which refers to
B/specificConfigForB.xml which refers to
B/somefile
Now specifying the location of somefile in specificConfigForB.xml should be
possible using a relative URL, such that it is possible to retrieve the
absolute URL of somefile through:
a) the absolute URL of A/config.xml (e.g.: file:/c:/A/config.xml or
http://A/config.xml)
b) the relative URL of somefile specified in B/specificConfigForB.xml (like
somefilesomefile/somefile)
(1) One solution is to make it possible to find the location of the
configuration file that specifies the relative URL. Or more general, commons
config should know where a given configuration item is stored.
In this case it might be an idea to implement a getURL() on the Configuration
interface which uses:
1. the absolute URL of the composite configuration file, (A/config.xml)
2. the relative URL to the specfying configuration file,
(B/specificConfigForB.xml)
3. the relative URL specified (in B/specificConfigForB.xml)
(2) Another solution is to specify a special meta variable (like ${url}) that
can be used to specify the location of the specifying configuration file wrt
the composite configuration file. E.g. somefile${url}/somefile/somefile
would result in ../B/somefile.
(3) Another solution would be to specify a special attribute to indicate that
the value specified is an URL. Like somefile type=URLsomefile/somefile.
The advantage of solution (1) is that no extra semantics are introduced to
the configuration files. Furthermore, it might possibly be useful in
debugging situations. The advantages of solution (2) is that in this manner
other meta variables might be introduced. The disadvantage of solution (3) is
that this one cannot be applied to property files.
See also
http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200606.mbox/[EMAIL
PROTECTED]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-155) [configuration] Instance specific list delimiter
[ https://issues.apache.org/jira/browse/CONFIGURATION-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-155. Resolution: Fixed Fix Version/s: Nightly Builds SubsetConfiguration and CompositeConfiguration have been updated to fully support an instance specific list delimiter. So this issue can be closed. [configuration] Instance specific list delimiter Key: CONFIGURATION-155 URL: https://issues.apache.org/jira/browse/CONFIGURATION-155 Project: Commons Configuration Issue Type: Improvement Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Emmanuel Bourg Priority: Minor Fix For: Nightly Builds Attachments: bug-35828-r2.patch, bug-35828.patch The delimiter used to split the properties is declared as a static field in AbstractConfiguration. That means we cannot have two instances of the same concrete implementation of AbstractConfiguration using a different delimiter. To adress this issue I suggest the following changes: - rename the private DELIMITER field into DEFAULT_LIST_DELIMITER - add the static methods setDefaultListDelimiter and getDefaultListDelimiter - deprecate get/setDelimiter in AbstractConfiguration in favor of get/setDefaultListDelimiter - add a non static field listDelimiter initialized with DEFAULT_LIST_DELIMITER - add the getListDelimiter and setListDelimiter methods to access the listDelimiter field - call getListDelimiter() instead of getDelimiter() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-78) [configuration] Inconsistent handling for keys that don't exist
[ https://issues.apache.org/jira/browse/CONFIGURATION-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-78: -- Fix Version/s: 2.0 Because such a change would affect existing code it should be made only in a major release. [configuration] Inconsistent handling for keys that don't exist --- Key: CONFIGURATION-78 URL: https://issues.apache.org/jira/browse/CONFIGURATION-78 Project: Commons Configuration Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: Ittay Dror Fix For: 2.0 The getXXX(String key) methods in AbstractConfiguration are not consistent in how they handle non-existing keys: getProperty(String key) - returns null getString(String key) - throws an exception if isThrowExceptionOnMissing is true getShort(String key) - throws an exception getStringArray(String key) - returns an empty array (why not null?) etc. I suggest that all these methods (include getProperty()) will check isThrowExceptionOnMissing and if true, throw an exception. As it is, it makes it hard to extend this class, and use Configuration in general. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-26) [configuration] Consider returning a concatenation of the list properties with getString()
[ https://issues.apache.org/jira/browse/CONFIGURATION-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-26: -- Fix Version/s: 2.0 Setting fix version to the next major release because this will probably involve an API change. [configuration] Consider returning a concatenation of the list properties with getString() -- Key: CONFIGURATION-26 URL: https://issues.apache.org/jira/browse/CONFIGURATION-26 Project: Commons Configuration Issue Type: Bug Environment: Operating System: All Platform: All Reporter: Ittay Dror Fix For: 2.0 in AbstractConfiguration.resolveContainerStore (javadoc): * Returns an object from the store described by the key. If the value is a * List object, replace it with the first object in the list. but what if getProperty returns a List because this is the type of the property? this code will silently grab the first elemen. I don't understand why. Probably the reason is that some class extending AbstractConfiguration returns List for properties. In this case I think the better approach is to have that class return the first element instead, rather than returning the List and letting AbstractConfiguration (which is used by many other implementations, including outside of the configuration package) handle it -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-247) recognize changes in included Propertiefiles
[ https://issues.apache.org/jira/browse/CONFIGURATION-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462549 ] Oliver Heger commented on CONFIGURATION-247: Implementing this feature is problematic because of the way include files in PropertiesConfiguration are currently handled: The properties found in included files are simply added to the current configuration object, and the connection to the source files is lost. One consequence of this is that if you save such a PropertiesConfiguration, the properties loaded from included files will be stored in the main properties file (rather than being written back to the original files). Support for include files is specific to PropertiesConfiguration and no general feature of (file-based) Configuration classes. With DefaultConfigurationBuilder and ConfigurationFactory Commons Configuration provides a more generic means of combining properties from different sources. The former allows defining reloading strategies for configurations that are to be combined together. Using this class you should be able to solve your problem. So I tend to close this issue as WON'T FIX unless you can give good reasons why you cannot use this alternative. recognize changes in included Propertiefiles Key: CONFIGURATION-247 URL: https://issues.apache.org/jira/browse/CONFIGURATION-247 Project: Commons Configuration Issue Type: New Feature Reporter: Mirko Wolf Properties-Files included in other properties-Files should be recognized by the event-listener / reloading-strategie set on the main properties-File. This is necessary in case of modifications in these included Files. for instance: main.properties include=sample.properties sample.properties [EMAIL PROTECTED] ... when i change the value of mail.address i definitly need a restart of my application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-246) The method getBasePath() in FileConfiguration suggest other behavior than it is implemented
[ https://issues.apache.org/jira/browse/CONFIGURATION-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-246. Resolution: Fixed Fix Version/s: Nightly Builds The Javadocs for getBasePath() and setBasePath() in both FileConfiguration and AbstractFileConfiguration have been improved. They now explain in more detail the background of the base path concept. The method getBasePath() in FileConfiguration suggest other behavior than it is implemented --- Key: CONFIGURATION-246 URL: https://issues.apache.org/jira/browse/CONFIGURATION-246 Project: Commons Configuration Issue Type: Improvement Reporter: Thomas Wabner Assigned To: Oliver Heger Fix For: Nightly Builds I have tried to use the FileConfiguration#getBasePath method without a look into the implementation. The documentation is not very useful because it says simple returns the base path. For me the method suggest that a string for the configuration file C:\myDir\config.file in form C:\myDir\ is returned. But the method returns the full path. I suggest to rename the method to getPath and give a documentation link to URL#getPath which does in fact the same. Or update the documentation which describes in more detail that this method returns the complete path for the associated file for this file configuration. A documentation entry can then looks like Returns the base path for the file associated with the current file configuration. The base path contains the full path to the file and the file itself. @see java.net.URL#getPath -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-192) [configuration] Enhancement of interpolation features
[ http://issues.apache.org/jira/browse/CONFIGURATION-192?page=all ]
Oliver Heger resolved CONFIGURATION-192.
Fix Version/s: Nightly Builds
Resolution: Fixed
The variable substitution features of the new Commons Lang text package have
been incorporated to implement enhanced variable interpolation. A new Class
ConfigurationInterpolator is responsible for interpolation. It manages a set of
lookup objects that are associated with specific variable prefixes. Standard
lookup objects for system properties and constants are provided. The user guide
was updated in this respect, too.
[configuration] Enhancement of interpolation features
-
Key: CONFIGURATION-192
URL: http://issues.apache.org/jira/browse/CONFIGURATION-192
Project: Commons Configuration
Issue Type: Improvement
Environment: Operating System: other
Platform: Other
Reporter: Oliver Heger
Assigned To: Oliver Heger
Priority: Minor
Fix For: Nightly Builds
Attachments: interpolation.diff, Interpolator.java,
Interpolator.java, TestInterpolator.java, TestInterpolator.java,
VariableResolver.java
At the moment interpolation is only supported by the getString() and
getStringArray() methods. This proposal suggests adding interpolation support
for other getter methods, too, and at the same time making it more
customizable
(including the ability to disable it at all).
A first step in achieving this could be to refactor the interpolation
functionality out of AbstractConfiguration and into a new Interpolator class.
This class would provide a main interpolation method and would also maintain
an
arbitrary number of objects that know how to resolve variables of certain
types.
Each Configuration object would be assigned an Interpolator instance, to which
it would delegate interpolation tasks.
Customization of the interpolation features could be done by assigning an
Interpolator object to a configuration that has been initialized with a custom
set of variable resolver objects. If no Interpolator is assigned, no
interpolation will be performed.
Variable resolver objects are very simple: They define a method which takes a
variable's name and return its value. The variable resolver to use for a
concrete variable is determined by a prefix that can be set for each variable.
So a variable like ${sys:user.home} e.g. might refer to the system properties
resolver. Variables without a prefix are handled by a default resolver, which
is
implemented by the Configuration object itself, so that the Configuration's
properties are used as variable values (which is backwards compatible to the
current functionality).
It should be possible to define a default Interpolator (or at least a default
set of variable resolvers) that is to be used by each Configuration object as
long as no special Interpolator is set. This could be done through a static
field in AbstractConfiguration.
Useful specific variable resolver classes could be:
- The already mentioned system properties resolver, which would make system
properties accessable in each configuration.
- A resolver that would read constant values from specified classes.
- A resolver that would evaluate expressions in an expression language like
EL.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-245) DatabaseConfiguration and JNDIConfiguration are eating exceptions
[ http://issues.apache.org/jira/browse/CONFIGURATION-245?page=comments#action_12461513 ] Oliver Heger commented on CONFIGURATION-245: Simply swallowing exceptions is certainly no good design. I agree that this should be changed. I wonder however if we should always throw runtime exceptions when such an internal error occurs. Maybe it would be better to make this behavior configurable. If the default behavior was to just log the exception, we would keep compatibility with earlier versions, but allow our users to change this. One way this could be achieved would be to enhance the existing event mechanism. In addition to normal configuration update events special error events could be generated. Interested parties could register themselves as error listeners at a configuration and would then be notified whenever a problem occurs. What do you think, would such an approach make sense? DatabaseConfiguration and JNDIConfiguration are eating exceptions - Key: CONFIGURATION-245 URL: http://issues.apache.org/jira/browse/CONFIGURATION-245 Project: Commons Configuration Issue Type: Bug Affects Versions: Nightly Builds, 1.3 Final Reporter: Hal Deadman DatabaseConfiguration and JNDIConfiguration and possibly others, really need to throw some sort of runtime exception to let the caller know the properties couldn't be read. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-200) [configuration] Add a size() method to the Configuration interface
[ http://issues.apache.org/jira/browse/CONFIGURATION-200?page=all ] Oliver Heger updated CONFIGURATION-200: --- Bugzilla Id: (was: 34263) Fix Version/s: 2.0 This is a binary incompatible change, so it needs a major release. [configuration] Add a size() method to the Configuration interface -- Key: CONFIGURATION-200 URL: http://issues.apache.org/jira/browse/CONFIGURATION-200 Project: Commons Configuration Issue Type: Improvement Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Emmanuel Bourg Priority: Minor Fix For: 2.0 The Configuration interface lacks a size() method, it makes sense to add it since we already have isEmpty(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-232) ConfigurationUtils spews directly on std.err when exceptions
[ http://issues.apache.org/jira/browse/CONFIGURATION-232?page=all ]
Oliver Heger resolved CONFIGURATION-232.
Fix Version/s: Nightly Builds
Resolution: Fixed
The printStackTrace() statements have been removed and the log messages you
pointed out have been improved. Thank you for spotting this.
ConfigurationUtils spews directly on std.err when exceptions
Key: CONFIGURATION-232
URL: http://issues.apache.org/jira/browse/CONFIGURATION-232
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.3 Final
Environment: n/a
Reporter: Endre Stølsvik
Assigned To: Oliver Heger
Priority: Minor
Fix For: Nightly Builds
ConfigurationUtils:
public static URL locate(String base, String name) {
3 x :
catch ([Malformed|IO]URLException e) {
e.printStackTrace();
}
}
.. say no more.
But while we're at it, the log-message (which, for some reason, actually goes
to a logger, not uglily to the system) states Configuration loaded from ..,
which isn't true: The thing isn't loaded yet; it will be loaded. Loading
configuration from .. would be better, or maybe Will be loading
configuration from ... In addition, these log-lines could state what was the
base, and in particular the case where it loads from base path, the whole
line reads wrong.
For example: Loading configuration [+name+] from base path [+base+]..
and similar for the other lines.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-239) setDelimiterParsingDisabled doesn't work for 'new PropertiesConfiguration(filePath)'
[ http://issues.apache.org/jira/browse/CONFIGURATION-239?page=all ] Oliver Heger resolved CONFIGURATION-239. Resolution: Invalid I think the documentation of setDelimiterParsingDisabled() describes the behavior appropriately. So closing this ticket. setDelimiterParsingDisabled doesn't work for 'new PropertiesConfiguration(filePath)' Key: CONFIGURATION-239 URL: http://issues.apache.org/jira/browse/CONFIGURATION-239 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Final Environment: Win XP SP2, IBM Java 1.4.2.x Reporter: Narciso Oliveira Junior Hi! just would like to report an issue I found with a new (and very helpful) improvement on version 1.3 of commons configuration, the issue is that setDelimiterParsingDisabled method doesn't work if first creates PropertiesConfiguration object using PropertiesConfiguration(filePath) constructor. I needed to create the PropertiesConfiguration object using PropertiesConfiguration(), use setDelimiterParsingDisabled(true) and then load the configration file using load(filePath) method. Please let me know if you need more details. thanks for all your work on this fabulous library...commons rocks! Narciso -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-246) The method getBasePath() in FileConfiguration suggest other behavior than it is implemented
[ http://issues.apache.org/jira/browse/CONFIGURATION-246?page=comments#action_12460341 ] Oliver Heger commented on CONFIGURATION-246: How did you initialize the configuration? Looking at the code in AbstractFileConfiguration the return value of getBasePath() seems to depend on the way the location of the configuration file was set. I think it is not true that getBasePath() always returns a full path. For instance in the setFile() and setURL() methods the base path is correctly set to the directory, to which the configuration file belongs. Renaming the method is not an option because we have to ensure backwards compatibility. Besides there is already a getPath() method in AbstractFileConfiguration. Maybe there are just too many ways of setting the file's location. But this is something we cannot change now either. The method getBasePath() in FileConfiguration suggest other behavior than it is implemented --- Key: CONFIGURATION-246 URL: http://issues.apache.org/jira/browse/CONFIGURATION-246 Project: Commons Configuration Issue Type: Improvement Reporter: Thomas Wabner I have tried to use the FileConfiguration#getBasePath method without a look into the implementation. The documentation is not very useful because it says simple returns the base path. For me the method suggest that a string for the configuration file C:\myDir\config.file in form C:\myDir\ is returned. But the method returns the full path. I suggest to rename the method to getPath and give a documentation link to URL#getPath which does in fact the same. Or update the documentation which describes in more detail that this method returns the complete path for the associated file for this file configuration. A documentation entry can then looks like Returns the base path for the file associated with the current file configuration. The base path contains the full path to the file and the file itself. @see java.net.URL#getPath -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-3) [configuration] Drop 1st class dependency on commons-logging
[ http://issues.apache.org/jira/browse/CONFIGURATION-3?page=all ] Oliver Heger resolved CONFIGURATION-3. -- Resolution: Won't Fix There is obviously not much interest in this issue any more, so I am closing it as wont't fix. The idea to allow a user setting a custom logger is not bad IMO. This functionality could be implemented in AbstractConfiguration, per default a NoOpLog could be set. If this is desired, please open a new enhancement request. [configuration] Drop 1st class dependency on commons-logging Key: CONFIGURATION-3 URL: http://issues.apache.org/jira/browse/CONFIGURATION-3 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Final 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-231) documentation: Get string returns null?
[ http://issues.apache.org/jira/browse/CONFIGURATION-231?page=all ] Oliver Heger resolved CONFIGURATION-231. Fix Version/s: Nightly Builds Resolution: Fixed I have added some @see tags pointing to setThrowExceptionOnMissing() to the relevant get methods and put an additional node to the class comment of AbstractConfiguration. Together with the class comment of the Configuration interface the documentation about missing properties should now be quite complete. The JavaDoc to getStringArray() was improved, too. I am marking this ticket as fixed. Feel free to reopen if you want to suggest further documentation improvements in this area. documentation: Get string returns null? --- Key: CONFIGURATION-231 URL: http://issues.apache.org/jira/browse/CONFIGURATION-231 Project: Commons Configuration Issue Type: Improvement Reporter: Thomas Wabner Assigned To: Oliver Heger Fix For: Nightly Builds Some open documentation issues: In the current documentation (1.3) there is for the Configuration#getString() method not documented, of this method returns a null string, if no value for the key was found. It should also be documented, if the given key can be null or not. For example if I can give a null key, null will be returned would be enough in this case. Configuration#getStringArray point not to a documentation (or gives no hint), that there is a way to configure the seperator for keys. Would be nice to have this in this place with a link to the seperator stuff. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-244) DefaultConfigurationBuilder depends on all the supported ConfigurationProviders
DefaultConfigurationBuilder depends on all the supported ConfigurationProviders --- Key: CONFIGURATION-244 URL: http://issues.apache.org/jira/browse/CONFIGURATION-244 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.3 Final Reporter: Oliver Heger Assigned To: Oliver Heger Priority: Minor DefaultConfigurationBuilder defines constants for the default configuration providers. Because these constants refer to the classes of the Configurations to be created there are much more dependencies than listed on the dependencies page (e.g. the provider for plist configurations depends on commons-digester). To avoid this the Configuration classes should not directly be specified as Class objects, but only by their name and then loaded when they are accessed for the first time (at least for these configurations that have external dependencies). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-244) DefaultConfigurationBuilder depends on all the supported ConfigurationProviders
[ http://issues.apache.org/jira/browse/CONFIGURATION-244?page=all ] Oliver Heger resolved CONFIGURATION-244. Fix Version/s: Nightly Builds Resolution: Fixed Classes that caused additonal dependencies are now resolved via reflection by the responsible ConfigurationProviders. DefaultConfigurationBuilder depends on all the supported ConfigurationProviders --- Key: CONFIGURATION-244 URL: http://issues.apache.org/jira/browse/CONFIGURATION-244 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.3 Final Reporter: Oliver Heger Assigned To: Oliver Heger Priority: Minor Fix For: Nightly Builds DefaultConfigurationBuilder defines constants for the default configuration providers. Because these constants refer to the classes of the Configurations to be created there are much more dependencies than listed on the dependencies page (e.g. the provider for plist configurations depends on commons-digester). To avoid this the Configuration classes should not directly be specified as Class objects, but only by their name and then loaded when they are accessed for the first time (at least for these configurations that have external dependencies). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-240) CombinedConfiguration does not reload when enclosed configuration files are modified.
[ http://issues.apache.org/jira/browse/CONFIGURATION-240?page=all ] Oliver Heger resolved CONFIGURATION-240. Fix Version/s: Nightly Builds Resolution: Fixed Should be fixed now in subversion and the next nightly build. CombinedConfiguration now provides a property called forceReloadCheck. If you set it to true, each property access will trigger the contained configurations, which will cause a reload if necessary. CombinedConfiguration does not reload when enclosed configuration files are modified. - Key: CONFIGURATION-240 URL: http://issues.apache.org/jira/browse/CONFIGURATION-240 Project: Commons Configuration Issue Type: Bug Environment: Windows XP, Java JVM 1.4 and up Reporter: Thomas DeBruycker Assigned To: Oliver Heger Fix For: Nightly Builds When getProperty() is called on a CombinedConfiguration object the reloadingRequired() method is not called. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-238) XMLConfiguration.save() - illegal new line char in xml comment
[ http://issues.apache.org/jira/browse/CONFIGURATION-238?page=comments#action_12456937 ] Oliver Heger commented on CONFIGURATION-238: Could you perhaps try your tests with a different XML parser and/or XSLT engine (maybe the newest versions of Xerces or Xalan)? I assume you use the versions that are shipped with the JRE, right? Thanks. XMLConfiguration.save() - illegal new line char in xml comment -- Key: CONFIGURATION-238 URL: http://issues.apache.org/jira/browse/CONFIGURATION-238 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Final Environment: Windows XP x64 Reporter: Janusz Studzizba I have the following conf.xml. ?xml version=1.0 encoding=UTF-8? report-server-config !-- comment new line in comment -- paramvalue/param /report-server-config Edited with Vim looks nice. I use XMLConfiguration to process it. I perform the following operations: XMLConfiguration config = new XMLConfiguration(c:\\conf.xml); config.save(); BUG: After config.save(); my conf.xml file, when edited in Vim, contains additional ^M char at the end of each line. This is very disturbing. REASON: There must be a bug in XMLConfiguration when operating on !-- -- xml comments which contain new line characters - as in my example. !-- comment new line in comment -- My original conf.xml contained 0D 0A chars as a new line in comment, after calling config.save(); there is ONLY 0A char there! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-243) Improve handling of optional configurations in DefaultConfigurationBuilder
[ http://issues.apache.org/jira/browse/CONFIGURATION-243?page=all ] Oliver Heger resolved CONFIGURATION-243. Fix Version/s: Nightly Builds Resolution: Fixed The new feature was added. The user guide was also updated. Improve handling of optional configurations in DefaultConfigurationBuilder -- Key: CONFIGURATION-243 URL: http://issues.apache.org/jira/browse/CONFIGURATION-243 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.3 Final Reporter: Oliver Heger Assigned To: Oliver Heger Priority: Minor Fix For: Nightly Builds So far a configuration declared as optional in the configuration definition file won't be added to the resulting combined configuration when its initialization causes an error. There are use cases where this behavior is not appropriate: Consider as an example an application that needs to store user specific settings in a user configuration file (e.g. stored in the user's home directory). The application's configuration definition file would include this user configuration and declare it as optional. When a user starts this application for the first time the user configuration does not exist; so its creation will cause an error and it won't be added to the combined configuration. Now every time the application wants to access the user configuration it has to check whether it exists and manually create it if necessary. Here it would be much easier if an empty configuration of the correct type was added to the combined configuration. This behavior could be controlled by an additional reserved attribute config-forceCreate of a configuration declaration. By the way: The nested class ConfigurationDeclaration of DefaultConfigurationBuilder should be public. This makes the implementation of custom configuration providers easier. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-243) Improve handling of optional configurations in DefaultConfigurationBuilder
Improve handling of optional configurations in DefaultConfigurationBuilder -- Key: CONFIGURATION-243 URL: http://issues.apache.org/jira/browse/CONFIGURATION-243 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.3 Final Reporter: Oliver Heger Assigned To: Oliver Heger Priority: Minor So far a configuration declared as optional in the configuration definition file won't be added to the resulting combined configuration when its initialization causes an error. There are use cases where this behavior is not appropriate: Consider as an example an application that needs to store user specific settings in a user configuration file (e.g. stored in the user's home directory). The application's configuration definition file would include this user configuration and declare it as optional. When a user starts this application for the first time the user configuration does not exist; so its creation will cause an error and it won't be added to the combined configuration. Now every time the application wants to access the user configuration it has to check whether it exists and manually create it if necessary. Here it would be much easier if an empty configuration of the correct type was added to the combined configuration. This behavior could be controlled by an additional reserved attribute config-forceCreate of a configuration declaration. By the way: The nested class ConfigurationDeclaration of DefaultConfigurationBuilder should be public. This makes the implementation of custom configuration providers easier. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-240) CombinedConfiguration does not reload when enclosed configuration files are modified.
[ http://issues.apache.org/jira/browse/CONFIGURATION-240?page=comments#action_12455114 ] Oliver Heger commented on CONFIGURATION-240: IMHO this seems to be rather a design flaw in the way reloading is implemented ATM than a bug. But I will see what I can do about it. CombinedConfiguration does not reload when enclosed configuration files are modified. - Key: CONFIGURATION-240 URL: http://issues.apache.org/jira/browse/CONFIGURATION-240 Project: Commons Configuration Issue Type: Bug Environment: Windows XP, Java JVM 1.4 and up Reporter: Thomas DeBruycker When getProperty() is called on a CombinedConfiguration object the reloadingRequired() method is not called. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-242) The configuration returned by HierarchicalConfiguration.subset() does not globally interpolate
The configuration returned by HierarchicalConfiguration.subset() does not globally interpolate -- Key: CONFIGURATION-242 URL: http://issues.apache.org/jira/browse/CONFIGURATION-242 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Final Reporter: Oliver Heger Assigned To: Oliver Heger Interpolation is only performed in the subset configuration itself. If the referenced property is not in the subset (but somewhere else in the parent configuration), it cannot be resolved. Interpolation should take all properties of the parent configuration into account. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-242) The configuration returned by HierarchicalConfiguration.subset() does not globally interpolate
[ http://issues.apache.org/jira/browse/CONFIGURATION-242?page=all ] Oliver Heger resolved CONFIGURATION-242. Fix Version/s: Nightly Builds Resolution: Fixed A fix was committed. The returned subset configuration now delegates to its parent for performing interpolation. The configuration returned by HierarchicalConfiguration.subset() does not globally interpolate -- Key: CONFIGURATION-242 URL: http://issues.apache.org/jira/browse/CONFIGURATION-242 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Final Reporter: Oliver Heger Assigned To: Oliver Heger Fix For: Nightly Builds Interpolation is only performed in the subset configuration itself. If the referenced property is not in the subset (but somewhere else in the parent configuration), it cannot be resolved. Interpolation should take all properties of the parent configuration into account. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-241) clearProperty() does not generate events
[ http://issues.apache.org/jira/browse/CONFIGURATION-241?page=all ]
Oliver Heger resolved CONFIGURATION-241.
Fix Version/s: Nightly Builds
Resolution: Fixed
Fixed now in subversion. Thank you for spotting this.
clearProperty() does not generate events
Key: CONFIGURATION-241
URL: http://issues.apache.org/jira/browse/CONFIGURATION-241
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.3 Final
Environment: Java 1.5, Windows XP
Reporter: Mike Whittemore
Fix For: Nightly Builds
I am loading configuration information from multiple sources and have
registered a listener with the resulting configuration object. Unfortunately
the listener does not receive clear property events. I've confirmed that it
can properly receive other events (like set property), and that calls to
clearProperty() do actually clear the property, so I believe this may be a
bug in commons-configuration. I've tried setting details to true, which had
no effect. Below is a watered down version of what I am doing (note, my
configuration file simply pulls in a property file containing this property:
name.first=Mike):
ConfigurationFactory configurationFactory = new ConfigurationFactory();
URL configFileURL = ... get the config file ...
configurationFactory.setConfigurationURL(configFileURL);
Configuration configuration = ConfigurationFactory.getConfiguration();
configuration.addConfigurationListener(new ConfigurationListener() {
public void configurationChanged(ConfigurationEvent e) {
System.out.println(e.getPropertyName() + : + e.getPropertyValue());
}
});
System.out.println(configuration.getProperty(name.first)); // prints Mike
configuration.claerProperty(name.first)); // no output whatsoever
System.out.println(configuration.getProperty(name.first)); // prints null
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-239) setDelimiterParsingDisabled doesn't work for 'new PropertiesConfiguration(filePath)'
[ http://issues.apache.org/jira/browse/CONFIGURATION-239?page=comments#action_12454749 ] Oliver Heger commented on CONFIGURATION-239: You are right, setting the delimiterParsingDisabled-flag has only effect *before* the configuration file is loaded. I just had a look in the JavaDoc for the 1.3 release and here for the setDelimiterParsingDisabled() method it is stated: Set whether this configuration should use delimiters when parsing property values to convert them to lists of values. By default delimiter parsing is enabled Note: this change will only be effective for new parsings. If you want it to take effect for all loaded properties use the no arg constructor and call this method before setting source. I think, this is quite clear, so I tend to close this ticket. What do you mean? setDelimiterParsingDisabled doesn't work for 'new PropertiesConfiguration(filePath)' Key: CONFIGURATION-239 URL: http://issues.apache.org/jira/browse/CONFIGURATION-239 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Final Environment: Win XP SP2, IBM Java 1.4.2.x Reporter: Narciso Oliveira Junior Hi! just would like to report an issue I found with a new (and very helpful) improvement on version 1.3 of commons configuration, the issue is that setDelimiterParsingDisabled method doesn't work if first creates PropertiesConfiguration object using PropertiesConfiguration(filePath) constructor. I needed to create the PropertiesConfiguration object using PropertiesConfiguration(), use setDelimiterParsingDisabled(true) and then load the configration file using load(filePath) method. Please let me know if you need more details. thanks for all your work on this fabulous library...commons rocks! Narciso -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-239) setDelimiterParsingDisabled doesn't work for 'new PropertiesConfiguration(filePath)'
[ http://issues.apache.org/jira/browse/CONFIGURATION-239?page=comments#action_12454113 ] Oliver Heger commented on CONFIGURATION-239: So what you need would be additional constructors that allow setting the delimiter parsing flag before the file is actually loaded, e.g. something like PropertiesConfiguration(String path, boolean delimiterParsingDisabled). Is this correct? I think this is possible. setDelimiterParsingDisabled doesn't work for 'new PropertiesConfiguration(filePath)' Key: CONFIGURATION-239 URL: http://issues.apache.org/jira/browse/CONFIGURATION-239 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Final Environment: Win XP SP2, IBM Java 1.4.2.x Reporter: Narciso Oliveira Junior Hi! just would like to report an issue I found with a new (and very helpful) improvement on version 1.3 of commons configuration, the issue is that setDelimiterParsingDisabled method doesn't work if first creates PropertiesConfiguration object using PropertiesConfiguration(filePath) constructor. I needed to create the PropertiesConfiguration object using PropertiesConfiguration(), use setDelimiterParsingDisabled(true) and then load the configration file using load(filePath) method. Please let me know if you need more details. thanks for all your work on this fabulous library...commons rocks! Narciso -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-234) Documentation - Dependencies - DefaultConfigurationBuilder needs commons-jxpath
[ http://issues.apache.org/jira/browse/CONFIGURATION-234?page=all ] Oliver Heger resolved CONFIGURATION-234. Fix Version/s: Nightly Builds Resolution: Fixed I fixed it the hard way: The dependency to commons-jxpath is no longer needed. Documentation - Dependencies - DefaultConfigurationBuilder needs commons-jxpath --- Key: CONFIGURATION-234 URL: http://issues.apache.org/jira/browse/CONFIGURATION-234 Project: Commons Configuration Issue Type: Task Affects Versions: 1.3 Final Reporter: Jean KST Assigned To: Oliver Heger Priority: Trivial Fix For: Nightly Builds java.lang.NoClassDefFoundError: org/apache/commons/jxpath/ri/model/NodePointerFactory when DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-238) XMLConfiguration.save() - illegal new line char in xml comment
[ http://issues.apache.org/jira/browse/CONFIGURATION-238?page=comments#action_12452003 ] Oliver Heger commented on CONFIGURATION-238: This is strange. There is no special handling of comment lines. XMLConfiguration does the following: It parses the XML configuration file using DOM and keeps the resulting DOM tree in memory. Updates of property values also cause this structure to be modified. When the save() method is called, an identity XSLT transformation is used to write the DOM tree back to a file (this will probably cause the ^M characters when the default new line separator 0D 0A is used for Windows). I have no idea why comments are treated differently. But as far as I can tell, this is not under the control of XMLConfiguration, but happens during the XML transformation. XMLConfiguration.save() - illegal new line char in xml comment -- Key: CONFIGURATION-238 URL: http://issues.apache.org/jira/browse/CONFIGURATION-238 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Final Environment: Windows XP x64 Reporter: Janusz Studzizba I have the following conf.xml. ?xml version=1.0 encoding=UTF-8? report-server-config !-- comment new line in comment -- paramvalue/param /report-server-config Edited with Vim looks nice. I use XMLConfiguration to process it. I perform the following operations: XMLConfiguration config = new XMLConfiguration(c:\\conf.xml); config.save(); BUG: After config.save(); my conf.xml file, when edited in Vim, contains additional ^M char at the end of each line. This is very disturbing. REASON: There must be a bug in XMLConfiguration when operating on !-- -- xml comments which contain new line characters - as in my example. !-- comment new line in comment -- My original conf.xml contained 0D 0A chars as a new line in comment, after calling config.save(); there is ONLY 0A char there! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-236) Outputting CombinedConfiguration as XML
[ http://issues.apache.org/jira/browse/CONFIGURATION-236?page=all ] Oliver Heger resolved CONFIGURATION-236. Fix Version/s: Nightly Builds Resolution: Fixed A copy constructor was added to HierarchicalConfiguration and most of its sub classes. You should now be able to copy a combined configuration into a XMLConfiguration. Outputting CombinedConfiguration as XML --- Key: CONFIGURATION-236 URL: http://issues.apache.org/jira/browse/CONFIGURATION-236 Project: Commons Configuration Issue Type: New Feature Affects Versions: 1.3 Final Reporter: Mark Chaimungkalanont Assigned To: Oliver Heger Fix For: Nightly Builds I have a CombinedConfiguration created from two XmlConfiguration objects. I want to output the combined XML of the CombinedConfiguration, but this doesn't currently seem possible. The CombinedConfiguration, through the NodeCombiner, seems to merge the hierarchy internally in any case, so I don't really see massive problem with outputting it as an XML. Logically the test would be: String xml = CombinedConfiguration.toXml(); CombinedConfiguration == XmlConfiguration(xml) So the that outputted XML of the CombinedConfiguration would be logically the same as the CombinedConfiguration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-238) XMLConfiguration.save() - illegal new line char in xml comment
[ http://issues.apache.org/jira/browse/CONFIGURATION-238?page=comments#action_12451728 ] Oliver Heger commented on CONFIGURATION-238: Sorry, I don't fully understand this issue. In which way exactly does the processed file differ from the original one? Are all lines modified or only comment lines? XMLConfiguration.save() - illegal new line char in xml comment -- Key: CONFIGURATION-238 URL: http://issues.apache.org/jira/browse/CONFIGURATION-238 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Final Environment: Windows XP x64 Reporter: Janusz Studzizba I have the following conf.xml. ?xml version=1.0 encoding=UTF-8? report-server-config !-- comment new line in comment -- paramvalue/param /report-server-config Edited with Vim looks nice. I use XMLConfiguration to process it. I perform the following operations: XMLConfiguration config = new XMLConfiguration(c:\\conf.xml); config.save(); BUG: After config.save(); my conf.xml file, when edited in Vim, contains additional ^M char at the end of each line. This is very disturbing. REASON: There must be a bug in XMLConfiguration when operating on !-- -- xml comments which contain new line characters - as in my example. !-- comment new line in comment -- My original conf.xml contained 0D 0A chars as a new line in comment, after calling config.save(); there is ONLY 0A char there! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-237) Contrib : managed reloading strategy
[ http://issues.apache.org/jira/browse/CONFIGURATION-237?page=comments#action_12451340 ] Oliver Heger commented on CONFIGURATION-237: Cool! I think JMX is an interesting area for the [configuration] component. However I will have to learn more before I really grasp what is going on here. For instance I do not understand how the connection between the Spring configuration you provided and a concrete instance of ManagedReloadingStrategy is established. I mean, you will probably have some code like ManagedReloadingStrategy strategy = new ManagedReloadingStrategy(); config.setReloadingStrategy(strategy); How does the MBeanExporter know that this specifc object is to be registered at the MBean server? Or do you use Spring to set up your configuration objects, too? Contrib : managed reloading strategy Key: CONFIGURATION-237 URL: http://issues.apache.org/jira/browse/CONFIGURATION-237 Project: Commons Configuration Issue Type: New Feature Affects Versions: Nightly Builds Reporter: nicolas de loof Priority: Minor Attachments: CONFIGURATION-237.patch, ManagedReloadingStrategyTest.java This patch adds a reloading strategy based on management request, typically from a JMX console. The Strategy implements a MBean interface so can be exported as a JMX Managed bean with no code change. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-237) Contrib : managed reloading strategy
[ http://issues.apache.org/jira/browse/CONFIGURATION-237?page=comments#action_12447925 ] Oliver Heger commented on CONFIGURATION-237: Looks interesting! Is there any chance that you can add a unit test for this class? I think, this won't be too complicated. Unfortunately I am no expert in JMX. Would it be possible for you to add an example about how this class can be used to the user guide? Or just attach a simple example and I will take care to add it to the guide. Many thanks! Contrib : managed reloading strategy Key: CONFIGURATION-237 URL: http://issues.apache.org/jira/browse/CONFIGURATION-237 Project: Commons Configuration Issue Type: New Feature Affects Versions: Nightly Builds Reporter: nicolas de loof Priority: Minor Attachments: CONFIGURATION-237.patch This patch adds a reloading strategy based on management request, typically from a JMX console. The Strategy implements a MBean interface so can be exported as a JMX Managed bean with no code change. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-229) config : load for a configuration node is called before parsing is complete : attributes ignored
[ http://issues.apache.org/jira/browse/CONFIGURATION-229?page=all ]
Oliver Heger resolved CONFIGURATION-229.
Fix Version/s: Nightly Builds
Resolution: Fixed
A fix was committed that causes the load() method to be invoked after
initialization of all specified properties is completed. This should solve this
problem. Please double-check.
Thanks!
config : load for a configuration node is called before parsing is complete :
attributes ignored
Key: CONFIGURATION-229
URL: http://issues.apache.org/jira/browse/CONFIGURATION-229
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.3 Final
Reporter: Andre Doherty
Assigned To: Oliver Heger
Priority: Minor
Fix For: Nightly Builds
Hi there
i have noticed the following issue which appears to be a bug. (Tested on 1.3
however the version doesn't appear above)
createObject from FileConfigurationFactory(DigesterConfigurationFactory) set
fileName and fires load of properties :
public Object createObject(Attributes attributes) throws Exception
{
FileConfiguration conf = createConfiguration(attributes);
conf.setBasePath(getBasePath());
conf.setFileName(attributes.getValue(ATTR_FILENAME));
try
{
log.info(Trying to load configuration +
conf.getFileName());
conf.load();
}
However digester invokes createObject when the object is instancied and
before setting any attributes.
All other attributes beside fileName and basePath are not read in time and
therefore are ignored during load.
I guess load should be called when node initialization is complete, possibly
using a proper digester rule.
Regards,
andré
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-227) ConfigurationDynaBean does not work well with all types of configurations
[ http://issues.apache.org/jira/browse/CONFIGURATION-227?page=all ] Oliver Heger resolved CONFIGURATION-227. Fix Version/s: Nightly Builds Resolution: Fixed A fix was applied that improves the compatibility of ConfigurationDynaBean with other configuration types, namely hierarchical configurations (there is also a new unit test class running all test cases on a XMLConfiguration). The only requirement is that the configuration uses the dot (.) as property delimiter. For hierarchical configurations that make use of a special expression engine this could be a problem. ConfigurationDynaBean does not work well with all types of configurations - Key: CONFIGURATION-227 URL: http://issues.apache.org/jira/browse/CONFIGURATION-227 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Final Reporter: Oliver Heger Assigned To: Oliver Heger Priority: Minor Fix For: Nightly Builds The current implementation of ConfigurationDynaBean makes some assumptions about the underlying Configuration object that are not met by all configuration implementations. Especially setting values for indexed properties by calling getList() and manipulating mapped properties through a subset configuration do not work for configurations derived from HierarchicalConfiguration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-235) variable interpolation problem
[ http://issues.apache.org/jira/browse/CONFIGURATION-235?page=all ]
Oliver Heger resolved CONFIGURATION-235.
Fix Version/s: Nightly Builds
Resolution: Fixed
Should be fixed in the next nightly builds. Thank you for spotting this.
variable interpolation problem
--
Key: CONFIGURATION-235
URL: http://issues.apache.org/jira/browse/CONFIGURATION-235
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.3 Final
Reporter: juergen schad
Fix For: Nightly Builds
interpolation of variables in Subsets doesn't work, if they are _not_
accessed via getString(). The following
example illustrates the problem:
BaseConfiguration oBase = new BaseConfiguration();
oBase.addProperty( a.b, new Integer(2) );
oBase.addProperty( a.c, ${a.b} );
// as expected: 2
int iValueBaseConfig = oBase.getInt( a.c );
String strValueBaseConfig = oBase.getString(a.c);
// as expected: 2
String strValueSubset = oBase.subset(a).getString(c);
// ConversionException, 'c' doesn't map to an Integer object
int iValueSubset = oBase.subset(a).getInt(c);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-233) Incomplete interpolation in CompositeConfiguration.getList()
[ http://issues.apache.org/jira/browse/CONFIGURATION-233?page=all ]
Oliver Heger resolved CONFIGURATION-233.
Fix Version/s: Nightly Builds
Resolution: Fixed
Patch applied. Thanks!
Incomplete interpolation in CompositeConfiguration.getList()
Key: CONFIGURATION-233
URL: http://issues.apache.org/jira/browse/CONFIGURATION-233
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.3 Final
Environment: Any.
Reporter: Rainer Jung
Fix For: Nightly Builds
Attachments: commons-configuration_1_3_patch.txt
Interpolsation is mostly done by AbstractConfiguration. All classes that
override get methods of AbstractConfiguration need to be careful not to break
interpolsation.
The class CompositeConfiguration overrides getList() to easily chain the
results of getList for its subconfigurations. The calls to getList() in the
subconfigurations does interpolsation but only inside the subconfiguration.
The combined lists never get interpolated in the whole
CompositeConfiguration. So whenever a reference in the value refers to a
property in another subconfiguration, interpolation breaks.
Since all the scalar get methods correctly interpolate between different sub
configurations, I assume, that this special behavior in getList() is not
intended.
A simple test case would be using the ConfigurationFactory with a config.xml,
that uses two property files x.properties:
x.1=a
x.2=b
and y.properties:
y=${x.1}, ${x.2}
and then calling getList for the key y.
The attached patch fixes the problem locally in CompositeConfiguration. It's
not very elegant, but tries to keep the fix local.
The patch should work for 1.2, 1.3 and trunk, since getList() in
CompositeConfiguration ist the same in these versions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-234) Documentation - Dependencies - DefaultConfigurationBuilder needs commons-jxpath
[ http://issues.apache.org/jira/browse/CONFIGURATION-234?page=comments#action_12445385 ] Oliver Heger commented on CONFIGURATION-234: You are right, this dependency is missing on our dependencies page. Now you mention it, I wonder if it is possible to implement DefaultConfigurationBuilder without the need of jxpath. For many users additional dependencies are a pain. I will do some investigations. Documentation - Dependencies - DefaultConfigurationBuilder needs commons-jxpath --- Key: CONFIGURATION-234 URL: http://issues.apache.org/jira/browse/CONFIGURATION-234 Project: Commons Configuration Issue Type: Task Affects Versions: 1.3 Final Reporter: Jean KST Priority: Trivial java.lang.NoClassDefFoundError: org/apache/commons/jxpath/ri/model/NodePointerFactory when DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-233) Incomplete interpolation in CompositeConfiguration.getList()
[
http://issues.apache.org/jira/browse/CONFIGURATION-233?page=comments#action_1273
]
Oliver Heger commented on CONFIGURATION-233:
You are right, this is a bug.
Your patch looks good. I hope I find some time soon to write a unit test and to
apply it.
Thanks for spotting this!
Incomplete interpolation in CompositeConfiguration.getList()
Key: CONFIGURATION-233
URL: http://issues.apache.org/jira/browse/CONFIGURATION-233
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.3 Final
Environment: Any.
Reporter: Rainer Jung
Attachments: commons-configuration_1_3_patch.txt
Interpolsation is mostly done by AbstractConfiguration. All classes that
override get methods of AbstractConfiguration need to be careful not to break
interpolsation.
The class CompositeConfiguration overrides getList() to easily chain the
results of getList for its subconfigurations. The calls to getList() in the
subconfigurations does interpolsation but only inside the subconfiguration.
The combined lists never get interpolated in the whole
CompositeConfiguration. So whenever a reference in the value refers to a
property in another subconfiguration, interpolation breaks.
Since all the scalar get methods correctly interpolate between different sub
configurations, I assume, that this special behavior in getList() is not
intended.
A simple test case would be using the ConfigurationFactory with a config.xml,
that uses two property files x.properties:
x.1=a
x.2=b
and y.properties:
y=${x.1}, ${x.2}
and then calling getList for the key y.
The attached patch fixes the problem locally in CompositeConfiguration. It's
not very elegant, but tries to keep the fix local.
The patch should work for 1.2, 1.3 and trunk, since getList() in
CompositeConfiguration ist the same in these versions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-230) XPathExpressionEngine nodeKey method create a wrong key for attribute node
[ http://issues.apache.org/jira/browse/CONFIGURATION-230?page=all ]
Oliver Heger resolved CONFIGURATION-230.
Fix Version/s: Nightly Builds
Resolution: Fixed
Should be fixed in the next nightly build. Thanks for spotting this!
XPathExpressionEngine nodeKey method create a wrong key for attribute node
--
Key: CONFIGURATION-230
URL: http://issues.apache.org/jira/browse/CONFIGURATION-230
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.3 Final
Environment: Any
Reporter: Andy Yeung
Assigned To: Oliver Heger
Fix For: Nightly Builds
Attachments: ConfigTest.java, ConfigTest.java
In org.apache.commons.configuration.tree.xpath.XPathExpressionEngine line 178
if (node.isAttribute())
{
buf.append(ATTR_DELIMITER);
}
should be changed to
if (node.isAttribute()) {
buf.append(NODE_PATH_DELIMITERS);
}
Using ATTR_DELIMITER will create key like [EMAIL PROTECTED] rather than
element/@attribute and make config reload fail.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-228) XMLConfiguration.subset() with FileChangedReloadingStrategy does *not* 'see' file changes
[ http://issues.apache.org/jira/browse/CONFIGURATION-228?page=all ] Oliver Heger resolved CONFIGURATION-228. Fix Version/s: Nightly Builds Resolution: Fixed I added some new test cases and committed a fix. Please double check. Thanks for spotting this! XMLConfiguration.subset() with FileChangedReloadingStrategy does *not* 'see' file changes - Key: CONFIGURATION-228 URL: http://issues.apache.org/jira/browse/CONFIGURATION-228 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Final Reporter: Janusz Studzizba Assigned To: Oliver Heger Fix For: Nightly Builds XMLConfiguration.subset() with FileChangedReloadingStrategy does *not* 'see' file changes Configuration.xml: conf parent-item sub-itemold_value/sub-item /parent-item /conf 1. XMLConfiguration is loaded: config = new XMLConfiguration(c:\\conf.xml); config.setReloadingStrategy(new FileChangedReloadingStrategy()); 2. Now, sub-item node value changes to new_value, and the code: Configuration parentItemConfig = config.subset(parent-item); [AA] String ss2 = parentItemConfig.getString(sub-item); returns old_value !!! while: config.getString(parent-item.sub-item); returns new refreshed value. It is a bug, we have FileChangedReloadingStrategy, we create new subset in [AA] but receive old values. [for now, workaround for config users is to call config.reload() when strategy.hasChanged()] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-231) documentation: Get string returns null?
[ http://issues.apache.org/jira/browse/CONFIGURATION-231?page=comments#action_12442298 ] Oliver Heger commented on CONFIGURATION-231: You are right, the information you mention is not easily to find. WDYT, would @see tags in the javadoc be appropriate that point to related methods like setThrowExceptionOnMissing() or setListDelimiter()? Or where would be the best way to place this information? documentation: Get string returns null? --- Key: CONFIGURATION-231 URL: http://issues.apache.org/jira/browse/CONFIGURATION-231 Project: Commons Configuration Issue Type: Improvement Reporter: Thomas Wabner Some open documentation issues: In the current documentation (1.3) there is for the Configuration#getString() method not documented, of this method returns a null string, if no value for the key was found. It should also be documented, if the given key can be null or not. For example if I can give a null key, null will be returned would be enough in this case. Configuration#getStringArray point not to a documentation (or gives no hint), that there is a way to configure the seperator for keys. Would be nice to have this in this place with a link to the seperator stuff. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-230) XPathExpressionEngine nodeKey method create a wrong key for attribute node
[
http://issues.apache.org/jira/browse/CONFIGURATION-230?page=comments#action_12442299
]
Oliver Heger commented on CONFIGURATION-230:
Do you have a code snippet (or even better a unit test) that demonstrates the
problem? We need to expose the bug first, so that we can verify that it is
resolved by the fix.
Thanks.
XPathExpressionEngine nodeKey method create a wrong key for attribute node
--
Key: CONFIGURATION-230
URL: http://issues.apache.org/jira/browse/CONFIGURATION-230
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.3 Final
Environment: Any
Reporter: Andy Yeung
In org.apache.commons.configuration.tree.xpath.XPathExpressionEngine line 178
if (node.isAttribute())
{
buf.append(ATTR_DELIMITER);
}
should be changed to
if (node.isAttribute()) {
buf.append(NODE_PATH_DELIMITERS);
}
Using ATTR_DELIMITER will create key like [EMAIL PROTECTED] rather than
element/@attribute and make config reload fail.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-229) config : load for a configuration node is called before parsing is complete : attributes ignored
[ http://issues.apache.org/jira/browse/CONFIGURATION-229?page=all ]
Oliver Heger updated CONFIGURATION-229:
---
Affects Version/s: 1.3 Final
(was: 1.2 Final)
Priority: Minor (was: Major)
You are right. This is the behavior since the first release. Do you have a
concrete use case why this does not work for you?
In 1.3 there is the new class DefaultConfigurationBuilder, which is able to
interprete the same configuration definition files as ConfigurationFactory.
This class does not use digester for parsing the XML files. It should set all
properties before the load() method is called. Can you give it a try?
Thanks.
config : load for a configuration node is called before parsing is complete :
attributes ignored
Key: CONFIGURATION-229
URL: http://issues.apache.org/jira/browse/CONFIGURATION-229
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.3 Final
Reporter: Andre Doherty
Priority: Minor
Hi there
i have noticed the following issue which appears to be a bug. (Tested on 1.3
however the version doesn't appear above)
createObject from FileConfigurationFactory(DigesterConfigurationFactory) set
fileName and fires load of properties :
public Object createObject(Attributes attributes) throws Exception
{
FileConfiguration conf = createConfiguration(attributes);
conf.setBasePath(getBasePath());
conf.setFileName(attributes.getValue(ATTR_FILENAME));
try
{
log.info(Trying to load configuration +
conf.getFileName());
conf.load();
}
However digester invokes createObject when the object is instancied and
before setting any attributes.
All other attributes beside fileName and basePath are not read in time and
therefore are ignored during load.
I guess load should be called when node initialization is complete, possibly
using a proper digester rule.
Regards,
andré
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-197) [configuration] INIConfiguration
[ http://issues.apache.org/jira/browse/CONFIGURATION-197?page=comments#action_12438203 ] Oliver Heger commented on CONFIGURATION-197: Had a look at the latest patch. It looks very good. Two points: - For legal reasons all files must contain the typical Apache license header. Can you add this (just copy the header from an existing source file)? - Is it possible for you to provide a unit test for your implementation? All classes must have a unit test before they are added to our code base. Maybe you can use the test case already attached to this ticket as a starting point? If not, I should be able to create a test myself. Thanks! [configuration] INIConfiguration Key: CONFIGURATION-197 URL: http://issues.apache.org/jira/browse/CONFIGURATION-197 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.0 Alpha Environment: Operating System: All Platform: All Reporter: Matthew Inger Priority: Minor Attachments: ini.zip, IniFileConfiguration.java, IniSectionConfiguration.java, testIniFile.ini, TestIniFileConfiguration.java Currently, configuration does not contain a way to read windows style .ini files. I am submitting an implementation of Configuration which supplies this functionality, along with a test program, and test data -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-228) XMLConfiguration.subset() with FileChangedReloadingStrategy does *not* 'see' file changes
[ http://issues.apache.org/jira/browse/CONFIGURATION-228?page=comments#action_12437659 ] Oliver Heger commented on CONFIGURATION-228: Sounds plausible. I will have a look. Is there any chance that you can provide a junit test? If not, that's no problem; I think the issue should not be too difficult to reproduce. XMLConfiguration.subset() with FileChangedReloadingStrategy does *not* 'see' file changes - Key: CONFIGURATION-228 URL: http://issues.apache.org/jira/browse/CONFIGURATION-228 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Final Reporter: Janusz Studzizba XMLConfiguration.subset() with FileChangedReloadingStrategy does *not* 'see' file changes Configuration.xml: conf parent-item sub-itemold_value/sub-item /parent-item /conf 1. XMLConfiguration is loaded: config = new XMLConfiguration(c:\\conf.xml); config.setReloadingStrategy(new FileChangedReloadingStrategy()); 2. Now, sub-item node value changes to new_value, and the code: Configuration parentItemConfig = config.subset(parent-item); [AA] String ss2 = parentItemConfig.getString(sub-item); returns old_value !!! while: config.getString(parent-item.sub-item); returns new refreshed value. It is a bug, we have FileChangedReloadingStrategy, we create new subset in [AA] but receive old values. [for now, workaround for config users is to call config.reload() when strategy.hasChanged()] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-224) BaseConfiguration.getProperty() returns reference to intenal store collection object instead of a clone
[ http://issues.apache.org/jira/browse/CONFIGURATION-224?page=all ] Oliver Heger resolved CONFIGURATION-224. Fix Version/s: Nightly Builds Resolution: Fixed A comment describing the behavior of getProperty() was added to the Configuration interface. So I am closing this ticket now. The problems with ConfigurationDynaBean are now dealt with in ticket CONFIGURATION-227. BaseConfiguration.getProperty() returns reference to intenal store collection object instead of a clone --- Key: CONFIGURATION-224 URL: http://issues.apache.org/jira/browse/CONFIGURATION-224 Project: Commons Configuration Issue Type: Bug Environment: 1.3RC2 Reporter: Gabriele Garuglieri Priority: Minor Fix For: Nightly Builds 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-228) XMLConfiguration.subset() with FileChangedReloadingStrategy does *not* 'see' file changes
[ http://issues.apache.org/jira/browse/CONFIGURATION-228?page=comments#action_12436935 ] Oliver Heger commented on CONFIGURATION-228: I think the problem here is that the subset configuration returned by XMLConfiguration is not life, i.e. it is not really connected to the parent configuration. There was a bug report (CONFIGURATION-212) describing this problem. In the current code base there is the new method configurationAt(String key) in HierarichicalConfiguration that returns a life configuration. You can try this method as an alternative. But maybe the subset() implementation should be changed to return a life subset, too. XMLConfiguration.subset() with FileChangedReloadingStrategy does *not* 'see' file changes - Key: CONFIGURATION-228 URL: http://issues.apache.org/jira/browse/CONFIGURATION-228 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Final Reporter: Janusz Studzizba XMLConfiguration.subset() with FileChangedReloadingStrategy does *not* 'see' file changes Configuration.xml: conf parent-item sub-itemold_value/sub-item /parent-item /conf 1. XMLConfiguration is loaded: config = new XMLConfiguration(c:\\conf.xml); config.setReloadingStrategy(new FileChangedReloadingStrategy()); 2. Now, sub-item node value changes to new_value, and the code: Configuration parentItemConfig = config.subset(parent-item); [AA] String ss2 = parentItemConfig.getString(sub-item); returns old_value !!! while: config.getString(parent-item.sub-item); returns new refreshed value. It is a bug, we have FileChangedReloadingStrategy, we create new subset in [AA] but receive old values. [for now, workaround for config users is to call config.reload() when strategy.hasChanged()] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-227) ConfigurationDynaBean does not work well with all types of configurations
ConfigurationDynaBean does not work well with all types of configurations - Key: CONFIGURATION-227 URL: http://issues.apache.org/jira/browse/CONFIGURATION-227 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Final Reporter: Oliver Heger Priority: Minor The current implementation of ConfigurationDynaBean makes some assumptions about the underlying Configuration object that are not met by all configuration implementations. Especially setting values for indexed properties by calling getList() and manipulating mapped properties through a subset configuration do not work for configurations derived from HierarchicalConfiguration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-226) Describe more accurate about the getBoolean() method
[ http://issues.apache.org/jira/browse/CONFIGURATION-226?page=all ] Oliver Heger resolved CONFIGURATION-226. Fix Version/s: Nightly Builds Resolution: Fixed Closing this ticket after more documentation was added. Feel free to reopen if you think that the documentation could be further improved. Describe more accurate about the getBoolean() method Key: CONFIGURATION-226 URL: http://issues.apache.org/jira/browse/CONFIGURATION-226 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.2 Final Reporter: Thomas Wabner Priority: Minor Fix For: Nightly Builds In the javadoc there is only described, that a boolean value is try to load in the Configuration#getBoolean() methods. But do you mean the Java Boolean values which are only working for strings like true and false or do you have a more lazy implementation like for string in the combination true, false, t, f, y, n and so on? The javadoc should speak more about this. Is it possible to add the mory lazy boolean loading stuff? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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
[ http://issues.apache.org/jira/browse/CONFIGURATION-224?page=comments#action_12435561 ] Oliver Heger commented on CONFIGURATION-224: For the incompatibility of ConfigurationDynaBean with some of the Configuration classes I have created a special ticket: CONFIGURATION-227 (I did some further testing and found out that there are more problems than dealing with lists). This is mainly to have this somewhere documented, I see no easy solution for this problem ATM. Meanwhile the vote for the release of Configuration 1.3 has passed, so these issues can be addressed later (which IMHO is no big problem, because the code in question exists since the very first release; so there is no need to hurry). Do you think that updating the documentation of the getProperty() method in the way outlined above would be a good idea? BaseConfiguration.getProperty() returns reference to intenal store collection object instead of a clone --- Key: CONFIGURATION-224 URL: http://issues.apache.org/jira/browse/CONFIGURATION-224 Project: Commons Configuration Issue Type: Bug Environment: 1.3RC2 Reporter: Gabriele Garuglieri Priority: Minor 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-225) Document exactly what's returned by ConfigurationEvent.getPropertyValue() after EVENT_ADD_PROPERTY.
[ http://issues.apache.org/jira/browse/CONFIGURATION-225?page=all ] Oliver Heger resolved CONFIGURATION-225. Fix Version/s: Nightly Builds Resolution: Fixed I added some notes to the javadoc of ConfigurationEvent and to the user's guide. I hope this is okay. Document exactly what's returned by ConfigurationEvent.getPropertyValue() after EVENT_ADD_PROPERTY. --- Key: CONFIGURATION-225 URL: http://issues.apache.org/jira/browse/CONFIGURATION-225 Project: Commons Configuration Issue Type: Improvement Environment: 1.3RC2 Reporter: Gabriele Garuglieri Assigned To: Oliver Heger Priority: Minor Fix For: Nightly Builds It should be documented that when the property content is a Collection, after EVENT_ADD_PROPERTY, ConfigurationEvent.getPropertyValue() returns only the value of what is being added to the property and not the whole property content as after EVENT_SET_PROPERTY. It took me a while to understand why in certain circumstances my testcases were failing :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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
[ http://issues.apache.org/jira/browse/CONFIGURATION-224?page=comments#action_12434537 ] Oliver Heger commented on CONFIGURATION-224: I am still reluctant to add this copy operation to getProperty(). The getter methods that deal with collections like getList() and getStringArray() will perform another copy because they need to do interpolation. (So if somebody holds a collection or array returned by these methods, there won't be a problem.) Maybe the documentation of getProperty() should be changed to state that this method (depending on a specific implementation) may return an object that is under the control of the configuration instance and should not be manipulated or considered constant over time. This won't help you with your current problem. But can't you do the copy yourself for collection objects? I guess you will have a special treatment for collections anyway to compare the single elements, haven't you? BaseConfiguration.getProperty() returns reference to intenal store collection object instead of a clone --- Key: CONFIGURATION-224 URL: http://issues.apache.org/jira/browse/CONFIGURATION-224 Project: Commons Configuration Issue Type: Bug Environment: 1.3RC2 Reporter: Gabriele Garuglieri Priority: Minor 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-226) Describe more accurate about the getBoolean() method
[ http://issues.apache.org/jira/browse/CONFIGURATION-226?page=comments#action_12434254 ] Oliver Heger commented on CONFIGURATION-226: The JavaDoc of the getBoolean() methods was updated to point to PropertyConfiguration.toBoolean() where the real conversion happens. Here the documentation now refers to the BooleanUtils class from Commons Lang, which performs the boolean conversion for us. I hope this makes usage of these methods clearer. Because Commons Lang already has a class for transforming string values to boolean, I don't want to add another implementation to Configuration. So if you need more string constants that should evaluate to true, I would suggest talking to the Lang team. Describe more accurate about the getBoolean() method Key: CONFIGURATION-226 URL: http://issues.apache.org/jira/browse/CONFIGURATION-226 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.2 Final Reporter: Thomas Wabner Priority: Minor In the javadoc there is only described, that a boolean value is try to load in the Configuration#getBoolean() methods. But do you mean the Java Boolean values which are only working for strings like true and false or do you have a more lazy implementation like for string in the combination true, false, t, f, y, n and so on? The javadoc should speak more about this. Is it possible to add the mory lazy boolean loading stuff? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-225) Document exactly what's returned by ConfigurationEvent.getPropertyValue() after EVENT_ADD_PROPERTY.
[ http://issues.apache.org/jira/browse/CONFIGURATION-225?page=comments#action_12433637 ] Oliver Heger commented on CONFIGURATION-225: Where would be the best place for such a documentation? In the JavaDocs of ConfigurationEvent or ConfigurationListener? Or better in AbstractConfiguration? I am not sure. Document exactly what's returned by ConfigurationEvent.getPropertyValue() after EVENT_ADD_PROPERTY. --- Key: CONFIGURATION-225 URL: http://issues.apache.org/jira/browse/CONFIGURATION-225 Project: Commons Configuration Issue Type: Improvement Environment: 1.3RC2 Reporter: Gabriele Garuglieri Priority: Minor It should be documented that when the property content is a Collection, after EVENT_ADD_PROPERTY, ConfigurationEvent.getPropertyValue() returns only the value of what is being added to the property and not the whole property content as after EVENT_SET_PROPERTY. It took me a while to understand why in certain circumstances my testcases were failing :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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
[ http://issues.apache.org/jira/browse/CONFIGURATION-224?page=comments#action_12433639 ] Oliver Heger commented on CONFIGURATION-224: Good catch. This also means that the way ConfigurationDynaBean is implemented ATM it will not properly work with other configuration types (e.g. XMLConfiguration) that do not return modifiable list objects. However I am not sure whether cloning a collection is the best solution. I would assume that directly manipulating a list object returned by getProperty() is rather unusual because there is no guarantee that this works for all configuration types. So by making use of cloning each call to getProperty() with collections involved would become more expensive only to deal with a special case. An alternative would be to return an unmodifiable collection (using Collections.unmodifiableCollection). But this would have to be exactly documented because it can impact existing code. WDYT? I would like to postpone this issue until the 1.3 release is out. BaseConfiguration.getProperty() returns reference to intenal store collection object instead of a clone --- Key: CONFIGURATION-224 URL: http://issues.apache.org/jira/browse/CONFIGURATION-224 Project: Commons Configuration Issue Type: Bug Environment: 1.3RC2 Reporter: Gabriele Garuglieri Priority: Minor 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-223) PropertiesConfigurationLayout broke the autoSave behaviour of PropertiesConfiguration
[ http://issues.apache.org/jira/browse/CONFIGURATION-223?page=all ] Oliver Heger resolved CONFIGURATION-223. Fix Version/s: Nightly Builds Resolution: Fixed The fix was committed. Everything seems to work now. Please double-check. Thanks. PropertiesConfigurationLayout broke the autoSave behaviour of PropertiesConfiguration - Key: CONFIGURATION-223 URL: http://issues.apache.org/jira/browse/CONFIGURATION-223 Project: Commons Configuration Issue Type: Bug Environment: 1.3RC1 Reporter: Gabriele Garuglieri Assigned To: Oliver Heger Priority: Critical Fix For: Nightly Builds Attachments: 223-test.patch When using PropertiesConfiguration with autoSave true the PropertiesConfigurationLayout causes invalid properties files to be saved. When using addProperty(key, value); where key does not exist yet in the configuration the EVENT_ADD_PROPERTY event that updates the PropertiesConfigurationLayout with the new key is issued only after the possiblySave() method is invoked so the new property will not be saved. When using setProperty(key, value); where key does not exist yet in the configuration the EVENT_SET_PROPERTY event that updates the PropertiesConfigurationLayout with the new key is issued only after the possiblySave() method is invoked so the new property will not be saved. The way it is implemented now makes content of the saved file depending on PropertiesConfigurationLayout content that depends on an event that will be issued only after the file was properly updated. This creates a circular dependency that cannot work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-223) PropertiesConfigurationLayout broke the autoSave behaviour of PropertiesConfiguration
[ http://issues.apache.org/jira/browse/CONFIGURATION-223?page=comments#action_12431362 ] Oliver Heger commented on CONFIGURATION-223: Thanks for the patch, this is really helpful. I changed AbstractFileConfiguration in the way mentioned above and everything seems to work. I will do some more testing. You are right that the behavior of these methods is now slightly different, but in this case I think it is an improvement. Calling addProperty() or setProperty() is now considered a single change and will result in only one auto save operation. This is fine IMO. Sorry for your JMX work. What makes me worrying is the fact that this significant bug was not detected by our unit test suite, though we have a pretty high code coverage. Obviously there is still room for improvement. PropertiesConfigurationLayout broke the autoSave behaviour of PropertiesConfiguration - Key: CONFIGURATION-223 URL: http://issues.apache.org/jira/browse/CONFIGURATION-223 Project: Commons Configuration Issue Type: Bug Environment: 1.3RC1 Reporter: Gabriele Garuglieri Assigned To: Oliver Heger Priority: Critical Attachments: 223-test.patch When using PropertiesConfiguration with autoSave true the PropertiesConfigurationLayout causes invalid properties files to be saved. When using addProperty(key, value); where key does not exist yet in the configuration the EVENT_ADD_PROPERTY event that updates the PropertiesConfigurationLayout with the new key is issued only after the possiblySave() method is invoked so the new property will not be saved. When using setProperty(key, value); where key does not exist yet in the configuration the EVENT_SET_PROPERTY event that updates the PropertiesConfigurationLayout with the new key is issued only after the possiblySave() method is invoked so the new property will not be saved. The way it is implemented now makes content of the saved file depending on PropertiesConfigurationLayout content that depends on an event that will be issued only after the file was properly updated. This creates a circular dependency that cannot work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-222) Saving PropertiesConfiguration created with PropertiesConfiguration() constructor creates empty files
[ http://issues.apache.org/jira/browse/CONFIGURATION-222?page=all ] Oliver Heger resolved CONFIGURATION-222. Fix Version/s: Nightly Builds Resolution: Fixed Patch applied. Very good work! Many thanks! Saving PropertiesConfiguration created with PropertiesConfiguration() constructor creates empty files - Key: CONFIGURATION-222 URL: http://issues.apache.org/jira/browse/CONFIGURATION-222 Project: Commons Configuration Issue Type: Bug Environment: 1.3RC1 Reporter: Gabriele Garuglieri Fix For: Nightly Builds Attachments: layout.patch The introduction of PropertiesConfigurationLayout broke the saving of in memory created PropertesConfiguration. This piece of code will yield empt saved file: PropertiesConfiguration pc = new PropertiesConfiguration(); pc.addProperty(string, value1); pc.save(testsave.properties); The problem is that no PropertiesConfigurationLayout is created and EVENT_ADD_PROPERTY is lost. Then when saving, an empty PropertiesConfigurationLayout is created and nothing is saved in output file. Added creation of PropertiesConfigurationLayout to PropertiesConfiguration() contructor, changed setLayout() to enforce that only one layout per PropertiesConfiguration must exist and added a testcase for this condition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-223) PropertiesConfigurationLayout broke the autoSave behaviour of PropertiesConfiguration
[ http://issues.apache.org/jira/browse/CONFIGURATION-223?page=comments#action_12431060 ] Oliver Heger commented on CONFIGURATION-223: Will have a closer look at this issue. Perhaps the problem could be solved when AbstractFileConfiguration did not override addPropertyDirect(), but addProperty() and setProperty() (for calling the possiblySave() method). This would also have the advantage that adding of properties with multiple values would cause only one save() operation instead of one per property value. PropertiesConfigurationLayout broke the autoSave behaviour of PropertiesConfiguration - Key: CONFIGURATION-223 URL: http://issues.apache.org/jira/browse/CONFIGURATION-223 Project: Commons Configuration Issue Type: Bug Environment: 1.3RC1 Reporter: Gabriele Garuglieri Assigned To: Oliver Heger Priority: Critical When using PropertiesConfiguration with autoSave true the PropertiesConfigurationLayout causes invalid properties files to be saved. When using addProperty(key, value); where key does not exist yet in the configuration the EVENT_ADD_PROPERTY event that updates the PropertiesConfigurationLayout with the new key is issued only after the possiblySave() method is invoked so the new property will not be saved. When using setProperty(key, value); where key does not exist yet in the configuration the EVENT_SET_PROPERTY event that updates the PropertiesConfigurationLayout with the new key is issued only after the possiblySave() method is invoked so the new property will not be saved. The way it is implemented now makes content of the saved file depending on PropertiesConfigurationLayout content that depends on an event that will be issued only after the file was properly updated. This creates a circular dependency that cannot work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-221) Allow system properties in config.xml
[ http://issues.apache.org/jira/browse/CONFIGURATION-221?page=all ] Oliver Heger resolved CONFIGURATION-221. Fix Version/s: Nightly Builds Resolution: Fixed Found some time today so I added a unit test and applied the patch to the current 1.3 trunk. Please double check. Many thanks again! Allow system properties in config.xml - Key: CONFIGURATION-221 URL: http://issues.apache.org/jira/browse/CONFIGURATION-221 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.2 Final Environment: All Reporter: Rainer Jung Assigned To: Oliver Heger Fix For: Nightly Builds Attachments: commons-configuration_1_2_patch.txt The attached patch allows system properties in the filename attributes of a config.xml file used in the factory. The patch is very simple, since commons-digester parses the file and has a built in capability to do the property substitution. The dependency of commons-configuration to commons-digester goes up from version 1.5 to 1.6. The most recent version 1.7 of commons-digester is not necessary. The patch can easily be ported to 1.3 and trunk. Use case: often the config.xml files are contained in a distribution unit like a war file, that should not be manipulated after packaging. The path names in config.xml need some way of making them externally variable so that the packaging unit can be adoped to a special environment without repackaging. By allowing system properties in the file names, this can be done easily. The implementation is simple, short and low risk. It would be nice, if you considered the patch for inclusion in the next release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-216) Inconsistent way to locate filename when creating configuration
[ http://issues.apache.org/jira/browse/CONFIGURATION-216?page=all ] Oliver Heger resolved CONFIGURATION-216. Fix Version/s: Nightly Builds Resolution: Fixed Marking this issue as resolved. Please double check and reopen if you still encounter problems. Inconsistent way to locate filename when creating configuration --- Key: CONFIGURATION-216 URL: http://issues.apache.org/jira/browse/CONFIGURATION-216 Project: Commons Configuration Issue Type: Bug Environment: commons-configuration-1.3-dev Reporter: Gabriele Garuglieri Assigned To: Oliver Heger Priority: Minor Fix For: Nightly Builds Attachments: 216-1.patch, resources.jar There is a different behaviour locating the configuration file in classpath depending on the way it is set in the configuration class. For example assuming conf/conf1.properties exists in classpath: PropertiesConfiguration pc = new PropertiesConfiguration(conf/conf1.properties); gives org.apache.commons.configuration.ConfigurationException: Cannot locate configuration source conf1.properties while PropertiesConfiguration pc = new PropertiesConfiguration(); pc.setFileName(conf/conf1.properties); pc.load(); properly locate file in classpath and loads it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-216) Inconsistent way to locate filename when creating configuration
[ http://issues.apache.org/jira/browse/CONFIGURATION-216?page=comments#action_12430092 ] Oliver Heger commented on CONFIGURATION-216: Patch applied. Many thanks! I made the following minor changes: - Changed the visibility of ConfigurationUtils.locateFromClasspath() to package scope; there is no need to make this method part of the public API. - Excluded the tests that try to access the jar file. We had some trouble with this jar (see ticket CONFIGURATION-71), which I don't want to have again. Regarding JMXConfiguration: That would be really cool. JMX is on our roadmap for future releases. Inconsistent way to locate filename when creating configuration --- Key: CONFIGURATION-216 URL: http://issues.apache.org/jira/browse/CONFIGURATION-216 Project: Commons Configuration Issue Type: Bug Environment: commons-configuration-1.3-dev Reporter: Gabriele Garuglieri Assigned To: Oliver Heger Priority: Minor Attachments: 216-1.patch, resources.jar There is a different behaviour locating the configuration file in classpath depending on the way it is set in the configuration class. For example assuming conf/conf1.properties exists in classpath: PropertiesConfiguration pc = new PropertiesConfiguration(conf/conf1.properties); gives org.apache.commons.configuration.ConfigurationException: Cannot locate configuration source conf1.properties while PropertiesConfiguration pc = new PropertiesConfiguration(); pc.setFileName(conf/conf1.properties); pc.load(); properly locate file in classpath and loads it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-216) Inconsistent way to locate filename when creating configuration
[ http://issues.apache.org/jira/browse/CONFIGURATION-216?page=all ] Oliver Heger updated CONFIGURATION-216: --- Attachment: (was: 216.patch) Inconsistent way to locate filename when creating configuration --- Key: CONFIGURATION-216 URL: http://issues.apache.org/jira/browse/CONFIGURATION-216 Project: Commons Configuration Issue Type: Bug Environment: commons-configuration-1.3-dev Reporter: Gabriele Garuglieri Assigned To: Oliver Heger Priority: Minor Attachments: 216-1.patch, resources.jar There is a different behaviour locating the configuration file in classpath depending on the way it is set in the configuration class. For example assuming conf/conf1.properties exists in classpath: PropertiesConfiguration pc = new PropertiesConfiguration(conf/conf1.properties); gives org.apache.commons.configuration.ConfigurationException: Cannot locate configuration source conf1.properties while PropertiesConfiguration pc = new PropertiesConfiguration(); pc.setFileName(conf/conf1.properties); pc.load(); properly locate file in classpath and loads it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-221) Allow system properties in config.xml
[ http://issues.apache.org/jira/browse/CONFIGURATION-221?page=comments#action_12430097 ] Oliver Heger commented on CONFIGURATION-221: Looks good! The 1.3 release will contain a class called DefaultConfigurationBuilder, which can be used as a substitute of ConfigurationFactory when hierarchical configurations are involved. This class provides support for variable substitution (as other configuration classes do). But for ConfigurationFactory your patch will be a nice enhancement. Is there any chance that you can provide a unit test case for this new feature? (New code is usually only added if corresponding tests exist.) Just ping me if you need help for creating such a test. Many thanks! Allow system properties in config.xml - Key: CONFIGURATION-221 URL: http://issues.apache.org/jira/browse/CONFIGURATION-221 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.2 Final Environment: All Reporter: Rainer Jung Attachments: commons-configuration_1_2_patch.txt The attached patch allows system properties in the filename attributes of a config.xml file used in the factory. The patch is very simple, since commons-digester parses the file and has a built in capability to do the property substitution. The dependency of commons-configuration to commons-digester goes up from version 1.5 to 1.6. The most recent version 1.7 of commons-digester is not necessary. The patch can easily be ported to 1.3 and trunk. Use case: often the config.xml files are contained in a distribution unit like a war file, that should not be manipulated after packaging. The path names in config.xml need some way of making them externally variable so that the packaging unit can be adoped to a special environment without repackaging. By allowing system properties in the file names, this can be done easily. The implementation is simple, short and low risk. It would be nice, if you considered the patch for inclusion in the next release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-216) Inconsistent way to locate filename when creating configuration
[ http://issues.apache.org/jira/browse/CONFIGURATION-216?page=comments#action_12429798 ] Oliver Heger commented on CONFIGURATION-216: I had a look at your patch. Looks good, and all unit tests are running. One change is problematic however: You removed the methods get/setPath() from AbstractFileConfiguration. This is a binary incompatible change, i.e. it would break existing code. So we can't do this. Is there a special reason why you deleted these methods? I am also a bit concerned regarding semantic compatibility. You had to change the testLocations() test case, which means that the behavior of some of the methods has changed. This could also have an impact on existing code. Wouldn't it be possible to keep the behavior of these methods and only do some additional checks in ConfigurationUtils.locate() ? In any case: Many thanks for your effort! Inconsistent way to locate filename when creating configuration --- Key: CONFIGURATION-216 URL: http://issues.apache.org/jira/browse/CONFIGURATION-216 Project: Commons Configuration Issue Type: Bug Environment: commons-configuration-1.3-dev Reporter: Gabriele Garuglieri Assigned To: Oliver Heger Priority: Minor Attachments: 216.patch There is a different behaviour locating the configuration file in classpath depending on the way it is set in the configuration class. For example assuming conf/conf1.properties exists in classpath: PropertiesConfiguration pc = new PropertiesConfiguration(conf/conf1.properties); gives org.apache.commons.configuration.ConfigurationException: Cannot locate configuration source conf1.properties while PropertiesConfiguration pc = new PropertiesConfiguration(); pc.setFileName(conf/conf1.properties); pc.load(); properly locate file in classpath and loads it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-220) getDateArray(String key, Date[] defaultValue, String format) ignores format argument
[ http://issues.apache.org/jira/browse/CONFIGURATION-220?page=all ] Oliver Heger resolved CONFIGURATION-220. Fix Version/s: Nightly Builds Resolution: Fixed Very good catch! Fixed in subversion. Many thanks! getDateArray(String key, Date[] defaultValue, String format) ignores format argument Key: CONFIGURATION-220 URL: http://issues.apache.org/jira/browse/CONFIGURATION-220 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Final Reporter: carl green Priority: Minor Fix For: Nightly Builds getDateArray(String key, Date[] defaultValue, String format) in DataConfiguration takes a format argument, but it is not used in the call to getDateList(key). This call should probably be getDateList(key, format). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-219) PropertiesConfiguration.clone() does not properly handle the layout object
[ http://issues.apache.org/jira/browse/CONFIGURATION-219?page=all ] Oliver Heger resolved CONFIGURATION-219. Fix Version/s: Nightly Builds Resolution: Fixed Fixed now in subversion: A clone() method was added to PropertiesConfiguration, which ensures that the layout object gets also copied. PropertiesConfiguration.clone() does not properly handle the layout object -- Key: CONFIGURATION-219 URL: http://issues.apache.org/jira/browse/CONFIGURATION-219 Project: Commons Configuration Issue Type: Bug Affects Versions: Nightly Builds Reporter: Oliver Heger Assigned To: Oliver Heger Fix For: Nightly Builds If a PropertiesConfiguration object is cloned, the clone will have the same PropertiesConfigurationLayout object. Of course this will cause trouble when later both objects are modified and then written to a file. PropertiesConfiguration needs a specific clone() implementation, which also clones the layout object. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-189) [configuration] Declaring reloadable configurations in the configuration descriptor
[ http://issues.apache.org/jira/browse/CONFIGURATION-189?page=all ] Oliver Heger resolved CONFIGURATION-189. Resolution: Fixed I am closing this issue now because the requested functionality is available in DefaultConfigurationBuilder. [configuration] Declaring reloadable configurations in the configuration descriptor --- Key: CONFIGURATION-189 URL: http://issues.apache.org/jira/browse/CONFIGURATION-189 Project: Commons Configuration Issue Type: Improvement Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Emmanuel Bourg Priority: Minor This is a proposal to support reloadable configurations in the configuration descriptor parsed by ConfigurationFactory. I suggest two forms, a complete form to fine tune the strategy applied to the configuration: configuration properties fileName=config.properties reloading-strategy class=org.apache.commons.configuration.reloading.FileChangedReloadingStrategy param name=refreshDelay value=3/ /reloading-strategy /properties /configuration and a short form: configuration properties fileName=config.properties reloadable=true/ /configuration This short form will use a FileChangedReloadingStrategy with the default values. This form keeps the descriptor simple for those that don't bother fine tuning the performance of the reloading mechanism. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-219) PropertiesConfiguration.clone() does not properly handle the layout object
PropertiesConfiguration.clone() does not properly handle the layout object -- Key: CONFIGURATION-219 URL: http://issues.apache.org/jira/browse/CONFIGURATION-219 Project: Commons Configuration Issue Type: Bug Affects Versions: Nightly Builds Reporter: Oliver Heger If a PropertiesConfiguration object is cloned, the clone will have the same PropertiesConfigurationLayout object. Of course this will cause trouble when later both objects are modified and then written to a file. PropertiesConfiguration needs a specific clone() implementation, which also clones the layout object. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-217) Possible Maven2 POM dependency clash for Servlet-API
[ http://issues.apache.org/jira/browse/CONFIGURATION-217?page=all ] Oliver Heger resolved CONFIGURATION-217. Fix Version/s: Nightly Builds Resolution: Fixed The dependency was updated to version 2.4 and marked as optional (because it is only needed by web configurations). I am in the process of preparing the first release candidate of Commons Configuration 1.3, so hopefully the next release is close. Possible Maven2 POM dependency clash for Servlet-API Key: CONFIGURATION-217 URL: http://issues.apache.org/jira/browse/CONFIGURATION-217 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Final Environment: Maven 2.0.4 Windows XP Reporter: Christoph Cenowa Priority: Minor Fix For: Nightly Builds As described by ASF bug #33476 Commons Configurations shall depend on Servlet-API 2.4. The current Maven2 POM of Commons Configuration 1.2 shows a dependency on Servlet-API 2.3. This is not only a mismatch between Commons Configurations' build configuration and its Maven2 POM but also prevents Maven2 projects from using the Servlet-API 2.4 if also using Commons Configuration 1.2. Could it be possible to fix Commons Configuration 1.2's Maven2 POM to include a dependency on Servlet-API 2.4, please? With best regards, Christoph P.S.: My thanks for the quick fix of the Commons Collection dependency problem within Commons Configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-104) [configuration] Preserve file structure (line comments) when re-saving properties file
[ http://issues.apache.org/jira/browse/CONFIGURATION-104?page=all ] Oliver Heger resolved CONFIGURATION-104. Resolution: Fixed A new class PropertiesConfigurationLayout was added. Objects of this class are associated with PropertiesConfiguration instances. They are able to preserve many structure related aspects of a properties file. Please have a look if this class fits your needs. [configuration] Preserve file structure (line comments) when re-saving properties file -- Key: CONFIGURATION-104 URL: http://issues.apache.org/jira/browse/CONFIGURATION-104 Project: Commons Configuration Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: Oded Noam Assigned To: Oliver Heger Attachments: preserve-comments-patch, preserve-comments-patch-java1.3 This bug applies when an application allows both manual editing of its configuration files, and manipulation of the configuration via software. When saving the configuration file after changing, its file structure - file, section and line comments - will all be lost. Next time a human tries to edit the configuration file, all property documentation will be lost. I have created a fix for this problem, applicable to PropertiesConfiguration and XMLPropertiesConfiguration. The fix allows these classes to preserve a list of comment lines preceding each property line. By default, comments are not preserved; in case the comment preservation is required, it should be enabled prior to loading the configuration file using: AbstractFileConfiguration.setDefaultPreserveComments(true); The fix is implemented and tested, attached as a patch file to this bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-140) [configuration] Header parsing for PropertiesConfiguration
[ http://issues.apache.org/jira/browse/CONFIGURATION-140?page=all ] Oliver Heger resolved CONFIGURATION-140. Fix Version/s: Nightly Builds Resolution: Fixed The header comment of a properties file is now maintained by a PropertiesConfigurationLayout instance. It is obtained on loading and written back on saving. [configuration] Header parsing for PropertiesConfiguration -- Key: CONFIGURATION-140 URL: http://issues.apache.org/jira/browse/CONFIGURATION-140 Project: Commons Configuration Issue Type: Improvement Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Emmanuel Bourg Priority: Minor Fix For: Nightly Builds The load method of PropertiesConfiguration should be able to set the header from the first comments at the beginning of the file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-170) [configuration] Add an option to save multiple values in one line
[ http://issues.apache.org/jira/browse/CONFIGURATION-170?page=all ] Oliver Heger resolved CONFIGURATION-170. Fix Version/s: Nightly Builds Resolution: Fixed You can now force PropertiesConfiguration to write all multi-valued properties on a single line on saving by doing: config.getLayout().setForceSingleLine(true); before you call save(). [configuration] Add an option to save multiple values in one line - Key: CONFIGURATION-170 URL: http://issues.apache.org/jira/browse/CONFIGURATION-170 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.2 Final Environment: Operating System: All Platform: All Reporter: Kenji Nakamura Priority: Minor Fix For: Nightly Builds I'd like to save a property to a file with List type value in one line. By default, the output looks like this. key = value1 key = value2 I want to make the output like this. key = value1, value2 Changing delimiter to '0' before calling save achieves the format, but retrieval of the value, say by calling getList(), results in returning a value value1, value2 instead of values value1 and value2, even if the original delimiter ',' is set back. In addition to that, the delimiter is defined as static and changing the value affects all threads, which is not typically desirable. It would be nice to have an option to save multiple values in a single line, with thread safe manner. Thanks, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-218) Formatter for properties file
[ http://issues.apache.org/jira/browse/CONFIGURATION-218?page=all ] Oliver Heger resolved CONFIGURATION-218: Resolution: Duplicate Ticket CONFIGURATION-104 deals with this topic. So resolving this as duplicate. Formatter for properties file - Key: CONFIGURATION-218 URL: http://issues.apache.org/jira/browse/CONFIGURATION-218 Project: Commons Configuration Type: New Feature Versions: 1.2 Final Reporter: Borut Bol?ina It would be cool to retain all formatting of the original properties file when writing back some new entry. If properties file is large and have many commented entries which are there as a remainder of all possible options that can be set, those commented entries should noot be deleted when saving configuration. As mentioned in http://issues.apache.org/jira/browse/CONFIGURATION-170, a formatter class of some kind would be the solution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-104) [configuration] Preserve file structure (line comments) when re-saving properties file
[
http://issues.apache.org/jira/browse/CONFIGURATION-104?page=comments#action_12419922
]
Oliver Heger commented on CONFIGURATION-104:
+1 for the idea of a Layout class that tries to obtain as much information as
possible from the properties file. I would like to start with a rather simple
one that can be enhanced step by step.
The collaboration between a PropertiesConfiguration object and its Layout
object could be as follows:
- The load(Reader) method of PropertiesConfiguration delegates to the Layout
object.
- The Layout object reads the file line by line and stores relevant
information, e.g. about comments, in internal data structures.
- Extracted properties are added to the PropertiesConfiguration.
- The Layout object is also registered as event listener at its
PropertiesConfiguration. If events are received, its content is updated
accordingly.
- PropertiesConfiguration.save(Writer) again delegates to the Layout object for
writing the data back to file.
So the interface of the layout class could roughly look as follows:
public class PropertiesConfigurationLayout implements ConfigurationListener
{
/**
* Creates a new instance and sets the associated configuration.
*/
public PropertiesConfigurationLayou(PropertiesConfiguration config);
/**
* Reads in a properties file.
*/
public void load(Reader in) throws ConfigurationException;
/**
* Writes the internal data into a properties file.
*/
public void save(Writer out) throws ConfigurationException;
// it would also be nice to have access to comments for properties
/**
* Returns the comment for the specified key.
*/
public String getComment(String key);
/**
* Sets the comment for the specified key.
*/
public void setComment(String key, String comment);
/**
* Returns the header comment.
*/
public String getHeaderComment();
/**
* Sets the header comment.
*/
public void setHeaderComment(String comment);
}
Any thoughts?
[configuration] Preserve file structure (line comments) when re-saving
properties file
--
Key: CONFIGURATION-104
URL: http://issues.apache.org/jira/browse/CONFIGURATION-104
Project: Commons Configuration
Type: Bug
Environment: Operating System: other
Platform: Other
Reporter: Oded Noam
Attachments: preserve-comments-patch, preserve-comments-patch-java1.3
This bug applies when an application allows both manual editing of its
configuration files, and manipulation of the configuration via software.
When
saving the configuration file after changing, its file structure - file,
section and line comments - will all be lost. Next time a human tries to edit
the configuration file, all property documentation will be lost.
I have created a fix for this problem, applicable to PropertiesConfiguration
and XMLPropertiesConfiguration. The fix allows these classes to preserve a
list of comment lines preceding each property line. By default, comments are
not preserved; in case the comment preservation is required, it should be
enabled prior to loading the configuration file using:
AbstractFileConfiguration.setDefaultPreserveComments(true);
The fix is implemented and tested, attached as a patch file to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-145) [configuration] clone() implementation for all configurations
[ http://issues.apache.org/jira/browse/CONFIGURATION-145?page=all ] Oliver Heger resolved CONFIGURATION-145: Fix Version: Nightly Builds Resolution: Fixed clone() methods have been added to the most important Configuration implementations, including CompositeConfiguration and CombinedConfiguration. [configuration] clone() implementation for all configurations - Key: CONFIGURATION-145 URL: http://issues.apache.org/jira/browse/CONFIGURATION-145 Project: Commons Configuration Type: Improvement Versions: 1.2 Final Environment: Operating System: All Platform: All Reporter: Mike Ferraro Assignee: Oliver Heger Priority: Minor Fix For: Nightly Builds Original email text: --- The HierarchicalConfiguration class contains a clone() method, to allow decoupling of a configuration from the underlying file to prevent ill effects during configuration updates. So, for example, I can clone an XMLConfiguration for a user's session in a web app and update the configuration file underneath so that the updates will be active for the next user and the current user will not experience some undesirable effect due to the change. My question is why this concept does not exist at a higher level? It would seem that any class that implements the FileConfiguration interface (and therefore the ReloadingStategy concept), should implement a method that allows the configuration to be temporarily decoupled from the source. Are there any plans for cloning to be enforced at a FileConfiguration level? From a completely selfish standpoint, I have a CompositeConfiguration object that contains several PropertiesConfigurations and XMLConfigurations with different reloading strategies. I'd like to clone this for each user session for the above mentioned reason. Ideally, the CompositeConfiguration would be clonable (cloning each of the encapsulated configurations), but barring that, it would be nice to be able to loop through the contained configurations and perform a FileConfiguration.clone() on each object. Or maybe there's another way to do this that I'm not seeing? TIA, Mike Mike, a consistent implementation of clone() methods would IMO make sense for most of the Configuration implementations. Would you be so kind to open an enhancement ticket for this in bugzilla, so this idea won't get lost (see http://jakarta.apache.org/commons/configuration/issue-tracking.html)? Thanks. What may help you ATM are some utility methods in ConfigurationUtils for copying configurations. You might have a look at this class and maybe you can use some of the stuff to solve your problem. Oliver -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-217) Possible Maven2 POM dependency clash for Servlet-API
[ http://issues.apache.org/jira/browse/CONFIGURATION-217?page=comments#action_12417890 ] Oliver Heger commented on CONFIGURATION-217: We have discussed this issue on the developers' list with some maven experts. Here is a link to this thread: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=115117131729595w=2 Outcome is that once released POMs should not be changed afterwards. I hope that the 1.3 release of Commons Configuration 1.3 won't be too far in future. Then we can update the dependency to Servlet API 2.4. Possible Maven2 POM dependency clash for Servlet-API Key: CONFIGURATION-217 URL: http://issues.apache.org/jira/browse/CONFIGURATION-217 Project: Commons Configuration Type: Bug Versions: 1.2 Final Environment: Maven 2.0.4 Windows XP Reporter: Christoph Cenowa Priority: Minor As described by ASF bug #33476 Commons Configurations shall depend on Servlet-API 2.4. The current Maven2 POM of Commons Configuration 1.2 shows a dependency on Servlet-API 2.3. This is not only a mismatch between Commons Configurations' build configuration and its Maven2 POM but also prevents Maven2 projects from using the Servlet-API 2.4 if also using Commons Configuration 1.2. Could it be possible to fix Commons Configuration 1.2's Maven2 POM to include a dependency on Servlet-API 2.4, please? With best regards, Christoph P.S.: My thanks for the quick fix of the Commons Collection dependency problem within Commons Configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-212) [configuration] The subset configuration returned by HierarchicalConfiguration is not life
[ http://issues.apache.org/jira/browse/CONFIGURATION-212?page=all ] Oliver Heger resolved CONFIGURATION-212: Resolution: Won't Fix With SubnodeConfiguration and the new method configurationAt() of HierarchicalConfiguration there is now a reasonable alternative for subset(). So this bug report can be closed. [configuration] The subset configuration returned by HierarchicalConfiguration is not life Key: CONFIGURATION-212 URL: http://issues.apache.org/jira/browse/CONFIGURATION-212 Project: Commons Configuration Type: Improvement Versions: Nightly Builds Environment: Operating System: other Platform: Other Reporter: Oliver Heger Priority: Minor For most Configuration implementations derived from AbstractConfiguration the Configuration object returned by the subset() method is connected to its original configuration. This means that changing either the subset or the original configuration will immediately have effect on each other. This is not the case for HierarchicalConfiguration and derived classes. The behavior of the subset() implementations should be made consistent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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
[ http://issues.apache.org/jira/browse/CONFIGURATION-3?page=comments#action_12417640 ] Oliver Heger commented on CONFIGURATION-3: -- What's the status of this issue? Is there still a desire to drop the commons logging dependency? I had a look at the places where logging is used. Some of them are unnecessary IMO. But for the following places we would need an aquivalent replacement: - ConfigurationFactory logs optional configurations that cannot be loaded. Maybe we could add a method to ConfigurationFactory that checks whether an optional configuration source could be loaded or not. - ConfigurationUtils.locate() logs the location from where a configuration file was loaded. Not sure if this makes too much sense: If a configuration has been successfully loaded, its URL can be checked. OTH it would be very useful when a configuration file could not be found to throw an exception that contains all the paths where it was searched for. However this won't be easy to implement. - JNDIConfiguration and DatabaseConfiguration swallow some exceptions and write them to the log. Here we would have to find an alternative. Maybe introduce a mode, in which such exceptions are re-thrown as runtime exceptions? [configuration] Drop 1st class dependency on commons-logging Key: CONFIGURATION-3 URL: http://issues.apache.org/jira/browse/CONFIGURATION-3 Project: Commons Configuration Type: Bug Versions: 1.2 Final 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-216) Inconsistent way to locate filename when creating configuration
[ http://issues.apache.org/jira/browse/CONFIGURATION-216?page=comments#action_12417354 ] Oliver Heger commented on CONFIGURATION-216: You are right! The problem did not occur to me because I use the maven build. And after a maven build ran successfully the ant build is successful, too, because maven copies the files to the right location. Well, I changed the copying stuff in build.xml, and now both builds should work. Sorry! Inconsistent way to locate filename when creating configuration --- Key: CONFIGURATION-216 URL: http://issues.apache.org/jira/browse/CONFIGURATION-216 Project: Commons Configuration Type: Bug Environment: commons-configuration-1.3-dev Reporter: Gabriele Garuglieri Assignee: Oliver Heger Priority: Minor There is a different behaviour locating the configuration file in classpath depending on the way it is set in the configuration class. For example assuming conf/conf1.properties exists in classpath: PropertiesConfiguration pc = new PropertiesConfiguration(conf/conf1.properties); gives org.apache.commons.configuration.ConfigurationException: Cannot locate configuration source conf1.properties while PropertiesConfiguration pc = new PropertiesConfiguration(); pc.setFileName(conf/conf1.properties); pc.load(); properly locate file in classpath and loads it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-216) Inconsistent way to locate filename when creating configuration
[ http://issues.apache.org/jira/browse/CONFIGURATION-216?page=all ] Oliver Heger resolved CONFIGURATION-216: Resolution: Fixed Should be fixed now in subversion, revision 416102. Please double check. Inconsistent way to locate filename when creating configuration --- Key: CONFIGURATION-216 URL: http://issues.apache.org/jira/browse/CONFIGURATION-216 Project: Commons Configuration Type: Bug Environment: commons-configuration-1.3-dev Reporter: Gabriele Garuglieri Assignee: Oliver Heger Priority: Minor There is a different behaviour locating the configuration file in classpath depending on the way it is set in the configuration class. For example assuming conf/conf1.properties exists in classpath: PropertiesConfiguration pc = new PropertiesConfiguration(conf/conf1.properties); gives org.apache.commons.configuration.ConfigurationException: Cannot locate configuration source conf1.properties while PropertiesConfiguration pc = new PropertiesConfiguration(); pc.setFileName(conf/conf1.properties); pc.load(); properly locate file in classpath and loads it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-215) Using relative URLs
[
http://issues.apache.org/jira/browse/CONFIGURATION-215?page=comments#action_12416623
]
Oliver Heger commented on CONFIGURATION-215:
Two thoughts:
- Such a method for checking from which source a property was loaded would only
make sense for composite configurations, i.e. ATM the classes
CompositeConfiguration and CombinedConfiguration, wouldn't it? For other -
simple - configurations the source is always the configuration itself.
- getURL() would only be a special case that is applicable to file-based
configurations. Maybe somewhen later somebody dealing with different database
configurations might want to find out, from which database table a certain
property was loaded. Then a URL would be useless. The same is true for JNDI
configurations you mentioned already.
So I would suggest the following solution: A method
Configuration getSource(String key);
can be added to composite configurations, which retrieves the source
configuration of a specified property.
For your special use case, when you know that you are dealing with file-based
configurations only, you can then do something like:
URL url = ((FileConfiguration)
compositeConfiguration.getSource(myProperty)).getURL();
Would this be okay with you?
Using relative URLs
---
Key: CONFIGURATION-215
URL: http://issues.apache.org/jira/browse/CONFIGURATION-215
Project: Commons Configuration
Type: Improvement
Reporter: Michiel Kalkman
Priority: Minor
It would be useful to be able to specify URLs in configuration item values
that are relative to the configuration.
A sample. I have the following files.
A/config.xml which refers to
B/specificConfigForB.xml which refers to
B/somefile
Now specifying the location of somefile in specificConfigForB.xml should be
possible using a relative URL, such that it is possible to retrieve the
absolute URL of somefile through:
a) the absolute URL of A/config.xml (e.g.: file:/c:/A/config.xml or
http://A/config.xml)
b) the relative URL of somefile specified in B/specificConfigForB.xml (like
somefilesomefile/somefile)
(1) One solution is to make it possible to find the location of the
configuration file that specifies the relative URL. Or more general, commons
config should know where a given configuration item is stored.
In this case it might be an idea to implement a getURL() on the Configuration
interface which uses:
1. the absolute URL of the composite configuration file, (A/config.xml)
2. the relative URL to the specfying configuration file,
(B/specificConfigForB.xml)
3. the relative URL specified (in B/specificConfigForB.xml)
(2) Another solution is to specify a special meta variable (like ${url}) that
can be used to specify the location of the specifying configuration file wrt
the composite configuration file. E.g. somefile${url}/somefile/somefile
would result in ../B/somefile.
(3) Another solution would be to specify a special attribute to indicate that
the value specified is an URL. Like somefile type=URLsomefile/somefile.
The advantage of solution (1) is that no extra semantics are introduced to
the configuration files. Furthermore, it might possibly be useful in
debugging situations. The advantages of solution (2) is that in this manner
other meta variables might be introduced. The disadvantage of solution (3) is
that this one cannot be applied to property files.
See also
http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200606.mbox/[EMAIL
PROTECTED]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-153) [configuration] use a Strategy pattern for locating resources
[ http://issues.apache.org/jira/browse/CONFIGURATION-153?page=comments#action_12416624 ] Oliver Heger commented on CONFIGURATION-153: I am interested in applying this patch for the next release of Commons Configuration to make the locating of configuration files more flexible. For this purpose we need some more things: - All new files need to have the header with the Apache license. You can copy this from existing files. - Can you use the same coding style or formatting options as the other source files use? - Is there any chance for you to come up with some unit tests for the new classes? Only tested code is added to our code base. You can have a look at the other unit tests under the src/tests directory. Or ping the dev-list if you need further support. Thanks! [configuration] use a Strategy pattern for locating resources - Key: CONFIGURATION-153 URL: http://issues.apache.org/jira/browse/CONFIGURATION-153 Project: Commons Configuration Type: Improvement Environment: Operating System: other Platform: Other Reporter: Joshua Nichols Priority: Minor Attachments: locator-strategy.patch Currently, the method for locating resources (ie ConfigurationUtils.locate ) uses a few means of finding the resource. However, the ways of finding resources are set in stone. At times, it would be useful to be able to pick and choose how resources are located. Here's an example: I have a webapp that builds a CompositeConfiguration composed of several PropertiesConfigurations (we'll say my.properties and default.properties) via spring. So, I go to kick off tomcat. If the current directory I'm in has a my.properties or default.properties those files get used instead of the ones on the classpath that I intended to be used. As a result, unexpected behavior of the webapp ensues. The solution to this is to encapsulate each algorithm for locating resoucess, and be able to pick and choose. To me, this screamed of the strategy pattern. A patch is forthcoming... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-215) Using relative URLs
[ http://issues.apache.org/jira/browse/CONFIGURATION-215?page=all ]
Oliver Heger updated CONFIGURATION-215:
---
Priority: Minor (was: Major)
Solution (1) would be hard to implement for some of the composite configuration
classes. I am not sure whether this effort is worth the value it gains because
finding out from which configuration source a certain property was loaded does
not seem to me to be such a typical use case - but I may be wrong.
Solution (3) is too specific for my taste.
Solution (2) would be my favorite because of the additional flexibility it
provides. For this request that would mean introducing a predefined variable
called ${config_url} or whatever that is replaced by the URL from which the
configuration file was loaded. However for composite configurations there is
still the problem how this variable should be resolved. This would require
knowledge from which source the property was loaded (same as (1)) and also
extending the variable substitution algorithm to take the property, in which
the variable is placed, into account.
Could you live with the following simpler approach: Configurations stored in a
composite configuration can be accessed either by a numeric index or (in the
case of CombinedConfiguration) by a name. So a composite configuration could
provide a family of meta variables of the form ${config_url.0},
${config_url.1}, or ${config_url_name}, which will be replaced by the URL of
the corresponding configuration source. Then it is in the responsibility of the
developer to choose the correct variable.
Using relative URLs
---
Key: CONFIGURATION-215
URL: http://issues.apache.org/jira/browse/CONFIGURATION-215
Project: Commons Configuration
Type: Improvement
Reporter: Michiel Kalkman
Priority: Minor
It would be useful to be able to specify URLs in configuration item values
that are relative to the configuration.
A sample. I have the following files.
A/config.xml which refers to
B/specificConfigForB.xml which refers to
B/somefile
Now specifying the location of somefile in specificConfigForB.xml should be
possible using a relative URL, such that it is possible to retrieve the
absolute URL of somefile through:
a) the absolute URL of A/config.xml (e.g.: file:/c:/A/config.xml or
http://A/config.xml)
b) the relative URL of somefile specified in B/specificConfigForB.xml (like
somefilesomefile/somefile)
(1) One solution is to make it possible to find the location of the
configuration file that specifies the relative URL. Or more general, commons
config should know where a given configuration item is stored.
In this case it might be an idea to implement a getURL() on the Configuration
interface which uses:
1. the absolute URL of the composite configuration file, (A/config.xml)
2. the relative URL to the specfying configuration file,
(B/specificConfigForB.xml)
3. the relative URL specified (in B/specificConfigForB.xml)
(2) Another solution is to specify a special meta variable (like ${url}) that
can be used to specify the location of the specifying configuration file wrt
the composite configuration file. E.g. somefile${url}/somefile/somefile
would result in ../B/somefile.
(3) Another solution would be to specify a special attribute to indicate that
the value specified is an URL. Like somefile type=URLsomefile/somefile.
The advantage of solution (1) is that no extra semantics are introduced to
the configuration files. Furthermore, it might possibly be useful in
debugging situations. The advantages of solution (2) is that in this manner
other meta variables might be introduced. The disadvantage of solution (3) is
that this one cannot be applied to property files.
See also
http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200606.mbox/[EMAIL
PROTECTED]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-214) Adding an integer and getting it as a long causes an exception
[ http://issues.apache.org/jira/browse/CONFIGURATION-214?page=all ] Oliver Heger resolved CONFIGURATION-214: Fix Version: Nightly Builds Resolution: Fixed Conversion features between different Number types were added. Adding an integer and getting it as a long causes an exception -- Key: CONFIGURATION-214 URL: http://issues.apache.org/jira/browse/CONFIGURATION-214 Project: Commons Configuration Type: Bug Versions: 1.2 Final Environment: Linux, java 1.5 Reporter: Sebastiano Vigna Assignee: Oliver Heger Priority: Minor Fix For: Nightly Builds Try this in a BeanShell: bsh % p = new org.apache.commons.configuration.PropertiesConfiguration(); bsh % p.setProperty(foo, 6); bsh % p.getLong(foo); // Error: // Uncaught Exception: Method Invocation p.getLong : at Line: 3 : in file: unknown file : p .getLong ( foo ) Target exception: org.apache.commons.configuration.ConversionException: 'foo' doesn't map to a Long object org.apache.commons.configuration.ConversionException: 'foo' doesn't map to a Long object at org.apache.commons.configuration.AbstractConfiguration.getLong(AbstractConfiguration.java:667) The problem is that when an object in a property is not a Long, the only attempt of PropertyConverter.toLong() is that of treating it as a string. It could try to convert it to a Number first and then try to convert it to a long. It is a very confusing behaviour, because if you save and reload the properties everything works fine (as now the integer is a string). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-214) Adding an integer and getting it as a long causes an exception
[ http://issues.apache.org/jira/browse/CONFIGURATION-214?page=all ] Oliver Heger updated CONFIGURATION-214: --- Assign To: Oliver Heger Adding an integer and getting it as a long causes an exception -- Key: CONFIGURATION-214 URL: http://issues.apache.org/jira/browse/CONFIGURATION-214 Project: Commons Configuration Type: Bug Versions: 1.2 Final Environment: Linux, java 1.5 Reporter: Sebastiano Vigna Assignee: Oliver Heger Priority: Minor Try this in a BeanShell: bsh % p = new org.apache.commons.configuration.PropertiesConfiguration(); bsh % p.setProperty(foo, 6); bsh % p.getLong(foo); // Error: // Uncaught Exception: Method Invocation p.getLong : at Line: 3 : in file: unknown file : p .getLong ( foo ) Target exception: org.apache.commons.configuration.ConversionException: 'foo' doesn't map to a Long object org.apache.commons.configuration.ConversionException: 'foo' doesn't map to a Long object at org.apache.commons.configuration.AbstractConfiguration.getLong(AbstractConfiguration.java:667) The problem is that when an object in a property is not a Long, the only attempt of PropertyConverter.toLong() is that of treating it as a string. It could try to convert it to a Number first and then try to convert it to a long. It is a very confusing behaviour, because if you save and reload the properties everything works fine (as now the integer is a string). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-214) Adding an integer and getting it as a long causes an exception
[ http://issues.apache.org/jira/browse/CONFIGURATION-214?page=comments#action_12413585 ] Oliver Heger commented on CONFIGURATION-214: I agree with you that this is a bug. Coversions between the Number types should be possible. Will have al look. Adding an integer and getting it as a long causes an exception -- Key: CONFIGURATION-214 URL: http://issues.apache.org/jira/browse/CONFIGURATION-214 Project: Commons Configuration Type: Bug Versions: 1.2 Final Environment: Linux, java 1.5 Reporter: Sebastiano Vigna Priority: Minor Try this in a BeanShell: bsh % p = new org.apache.commons.configuration.PropertiesConfiguration(); bsh % p.setProperty(foo, 6); bsh % p.getLong(foo); // Error: // Uncaught Exception: Method Invocation p.getLong : at Line: 3 : in file: unknown file : p .getLong ( foo ) Target exception: org.apache.commons.configuration.ConversionException: 'foo' doesn't map to a Long object org.apache.commons.configuration.ConversionException: 'foo' doesn't map to a Long object at org.apache.commons.configuration.AbstractConfiguration.getLong(AbstractConfiguration.java:667) The problem is that when an object in a property is not a Long, the only attempt of PropertyConverter.toLong() is that of treating it as a string. It could try to convert it to a Number first and then try to convert it to a long. It is a very confusing behaviour, because if you save and reload the properties everything works fine (as now the integer is a string). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
