In GlobalIds.java
public static final String TRUST_STORE = Config.getProperty( "trust.store"
);
public static final String TRUST_STORE_PW = Config.getProperty(
"trust.store.password" );
In Config.java:getExternalConfig()
...
config.setProperty( GlobalIds.TRUST_STORE, szValue );
...
By the time getExternalConfig is called, the fortress.properties has been read.
This forces the code to evaluate TRUST_STORE = Config.getProperty(
"trust.store" );
Now the value of some path becomes the key - the result is that an external
value will never be used because nowhere in the code is the key known.
It should be fixed in GlobalIds so that the field is only the key, and all
usage of this key (in ApacheDsDataProvider.java) should be replaced with
Config.getProperty("...");
There could be subtle issues with other static fields in GlobalIds which
depends on Config.getProperty(...).
In our case we want to extend ConfigMgrImpl as a point for reading our own
params. I know about fortress.user.properties, but one hardcoded file is too
limited. We want to support multiple environments (for test, development and
prod). All environments are started with an "autorola_env" system property. I
can use that to read the right file or to use our config-tool which handles a
special property-syntax that allows to set properties for multiple environments
in one file. But with the current setup, the call to our ConfigMgrImpl comes in
after GlobalIds have had its static initializers run (- and possibly too late
for the DAO's too). I think that I will have to add a step similar to
fortress.user.properties but with a dynamic filename. I guess I could fiddle
with build and deploy to generate the right file at the right moment.
// Jan
