[
https://issues.apache.org/jira/browse/CONFIGURATION-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16279161#comment-16279161
]
Oliver Heger commented on CONFIGURATION-677:
--------------------------------------------
So far the setting whether a configuration source is optional has been seen as
a property of the builder that creates the configuration and not of the
configuration itself. It may be possible and beneficial to implement this as a
configuration property. It would then have to be placed in one of the parameter
objects.
I would not go so far to introduce a priority for location strategies to
determine a default path for optional sources. This solution seems to be too
clever and will be hard to understand. It may already be sufficient to just
specify a default location explicitly.
> FileBasedConfigurationBuilder allowFailOnInit vs HomeDirectoryLocationStrategy
> ------------------------------------------------------------------------------
>
> Key: CONFIGURATION-677
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-677
> Project: Commons Configuration
> Issue Type: Bug
> Components: Documentation, File reloading
> Affects Versions: 2.2
> Environment: macOS Sierra 10.12.6, Java 1.8.0_152
> Reporter: Piotr Skowronek
> Fix For: 2.x
>
>
> It seems there's a problem with configuration creation when using
> FileBasedConfigurationBuilder with allowFailOnInit together with
> HomeDirectoryLocationStrategy and autoSave option.
> If the configuration is present in user.home directory (let's say
> ~/.some.config) it is being loaded and updated properly, but if the file does
> *not exist* then the configuration is created in current working directory
> (where the java program was launched) and *not* in user home directory.
> Javadoc of BasicConfigurationBuilder states as follows:
> {quote}A builder instance can be constructed with an <em>allowFailOnInit</em>
> * flag. If set to <strong>true</strong>, exceptions during initialization
> * of the configuration are ignored; in such a case an empty configuration
> * object is returned. A use case for this flag is a scenario in which a
> * configuration is optional and created on demand the first time
> configuration
> * data is to be stored. Consider an application that stores user-specific
> * configuration data in the user's home directory: When started for the first
> * time by a new user there is no configuration file; so it makes sense to
> * start with an empty configuration object. On application exit, settings
> * can be stored in this object and written to the associated file. Then they
> * are available on next application start.
> {quote}
> So, either it is a bug and it should be fixed in the Configuration project or
> it is the correct behavior and it is the programmer to ensure to write the
> configuration in the right place for the first time. If the latter then I
> would suggest to update javadoc to state that clearly enough (and maybe
> provide an example on the project website).
> Code sample:
> {code}
> // file not present: ~/.some.config
> BuilderParameters params = new
> Parameters().properties().setFileName(".some.config")
> .setLocationStrategy(new HomeDirectoryLocationStrategy());
> builder = new
> FileBasedConfigurationBuilder<FileBasedConfiguration>(PropertiesConfiguration.class,
> params.getParameters(), true);
> builder.setAutoSave(true);
> config = builder.getConfiguration();
> config.setProperty("test", "test);
> // config file .some.config not present in ~/.some.config but present
> in CWD
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
