Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
1.1
-
None
-
None
-
None
-
Operating System: Windows 2000
Platform: PC
-
35621
Description
The "include" property fails in 1.1 when a PropertiesConfiguration is
instantiated with a relative path/file name instead of an absolute path, but it
works correctly in version 1.0.
As far as I can tell this bug was introduced by the refactoring of the load()
behavior from the PropertiesConfiguration constructor to the constructor of
AbstractFileConfiguration. The load() method relies on the instance variable
"includesAllowed" which is declared and initialized in PropertiesConfiguration.
However, because in v1.1 load() is invoked from the superclass constructor, the
instance variables in the subclass have not yet been initialized when load() is
invoked. Consequently "includesAllowed" evaluates to false and the include fails.
I have attached a simple app to illustrate the issue. It attempts to load the
property "bar" via an included properties file from the config dir. By
manipulating the classpath in a batch script the app can be run twice, once
using version 1.0 and once using 1.1. Here is sample output:
Configuration version 1.0...
file name = myapp.properties
base path = file:/C:/myapp/config/
includes? = true
foo=foo from properties
bar=included bar
Configuration version 1.1...
file name = myapp.properties
base path = null
includes? = true
foo=foo from properties
bar=null
Note that the output contains "includes? = true" (which displays the result of
PropertiesConfiguration.getIncludesAllowed()), but this occurs after the
configuration has been completely initialized.