On Friday, February 26, 2016, sebb <[email protected]> wrote: > On 25 February 2016 at 23:59, sebb <[email protected] <javascript:;>> > wrote: > > On 25 February 2016 at 22:36, Philippe Mouawad > > <[email protected] <javascript:;>> wrote: > >> Hello, > >> > >> In JMeter we usually manage properties this way: > >> public String getImplementation() { > >> return getPropertyAsString(IMPLEMENTATION, DEFAULT_POLICY); > >> } > >> > >> public void setImplementation(String implementation){ > >> setProperty(IMPLEMENTATION, implementation, DEFAULT_POLICY); > >> } > >> > >> > >> setProperty will not save in JMX the value if it is equal to > DEFAULT_POLICY. > >> This is good for the size of JMX but it's an issue for migration when we > >> change default values in N+1 and load the JMX plan in this new plan. > >> > >> You can see an illustration through : > >> https://bz.apache.org/bugzilla/show_bug.cgi?id=58756#c2 > >> > -------------------------------------------------------------------------------------------------------------- > >> > >> The issue is that when reading a 2.13 saved JMX from a 3.0, as default > have > >> changed, the default values are not in JMX file so we end up > initializing > >> different values. > >> > >> > -------------------------------------------------------------------------------------------------------------- > >> > >> > >> So I think we should abandon this practice in favor of explicit > defaults. > > > > That is not necessary. > > > > If a default changes, just drop the default from the setProperty call. > > The value will then always be saved. > > On reflection, although that works for new test plans it breaks > compatibility, as it changes the meaning of the original JMX files. > > Once a default is established for the JMX, it should never be changed
That's impossible sebb, take this particular case, Hc4 based cookie handler is the new default with a policy that didn't exist in jmeter2.13. Also sometimes you make a bad choice on default and not being able to change it is a problem. > > But this does not mean that we cannot change the default for *new* > test elements. Yes but here cookiemanager is not a new element. > > That is easy to do - just change the GUI code to use a different > default for the GUI field. > > [Often the default is just the empty string, so it's perhaps not > obvious that it is the default.] > > >> Second question, how can we fix this issue ? > >> upgrade.properties used by NameUpdater does some upgrade but not on > default > >> values. > > I suppose that would be a way to change the JMX defaults, but it would > mean more code/testing/maintenance merely to reduce the JMX size. What shall we do here ? Inform users that they need to update the policy of cookiemanager after upgrading to 3.0 ? > > > As above. > > > >> > >> Thanks > >> Regards > >> Philippe M. > >> @philmdot > -- Cordialement. Philippe Mouawad.
