Community
Participate
Working Groups
Tom and I were talking about the problem where we have a shared install and the user has values in their config.ini which cause the install to not load. (for instance after the root user has updated the shared install) One approach to this would be to implement a mechanism where by the user config.ini values for certain properties could be ignored. We've agreed to the following approach: - we will look for <propertyname>.override.user - it can be set either in the config.ini from the shared location or by a -D parm on the command line - if the override property is set (to be any value: getProperty() != null) then the value from the shared install area will override any value from the user config.ini - if a property value is set via the command-line (e.g. -Dkey=value) then that value will not be over-written
Created attachment 183124 [details] patch
DJ, when we discussed this approach there was a question on whether the *.override.user properties should show up in the merged configuration (destination). The patch appears to not place the *.override.user properties into the destination. Is that the intention? I thought you were leaning towards including the *.override.user props in the destination properties.
Hmm... yeah I forgot about that. I'll change it. My argument at the time was that it will be easier to debug down the road if we have customer problems and we receive a system properties dump.
yeah, the other argument to keep the *.override.user properties is in case someone defined their own property that ended with .override.user. The current patch would ignore them altogether.
Why would someone do that?? Serves them right! ;-)
I think another change to the patch should be to always let the command-line args win. Tom, what do you think? With the current patch: - user calls exe with -Dfoo=bar - user config.ini has no entry for foo - shared config has entry foo=anotherBar and foo.override.user=true In this case the result will be foo=anotherBar.
(In reply to comment #6) > I think another change to the patch should be to always let the command-line > args win. Tom, what do you think? > > With the current patch: > - user calls exe with -Dfoo=bar > - user config.ini has no entry for foo > - shared config has entry foo=anotherBar and foo.override.user=true > > In this case the result will be foo=anotherBar. Yes, I think -D options should win.
Created attachment 183174 [details] patch Updated patch which keeps track of all the keys in the System properties before we start our modifications so we can check later to ensure we don't overwrite any values set on the command-line.
Created attachment 183238 [details] Alternate patch This patch avoids taking a snapshot of system property keys by passing the userConfiguration properties object to the mergeProperties for the override case (null is passed for the non-override case instead of false).
Comment on attachment 183174 [details] patch Ok, your patch is good. Thanks Tom.
I went ahead and released the latest patch to HEAD to get more testing before M4 is final.
set wrong milestone, sorry for the spam.
