commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piotr Skowronek (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CONFIGURATION-677) FileBasedConfigurationBuilder allowFailOnInit vs HomeDirectoryLocationStrategy
Date Sun, 03 Dec 2017 12:48:00 GMT

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

Piotr Skowronek updated CONFIGURATION-677:
------------------------------------------
    Description: 
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}




  was:
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 follow:
{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}





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

Mime
View raw message