> On Jan 12, 2016, at 1:42 PM, Jan Sindberg <[email protected]> wrote: > >> Fra: Shawn McKinney [mailto:[email protected]] >> Sendt: 12. januar 2016 15:54 >> Til: [email protected] >> Emne: Re: Config - override properties bug? > > > I have brought up two topics in this thread (I should remember not to have > more than one pr. thread :-) ). The first I suspect is a bug: The > documentation on configuration mentions that you can override trust.store and > trust.store.pw through system properties - and the code shows intent of that > but fails in actually supporting it. Can I add such findings to Jira > directly? I hope that I will have time to propose a patch soon if we agree. > I will repeat here for clarity: > > 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(...).
Yes, please create a JIRA and we’ll address the issue there. > > On Jan 12, 2016, at 1:42 PM, Jan Sindberg <[email protected]> wrote: > > > The other topic is about supporting multiple environments (including > developers locally). I will throw that into another thread. Sounds good. Thanks, Shawn
