There are still more fixes to be applied; looks like some unit tests were 'fixed' to avoid test failures.
On 27 February 2016 at 10:23, Philippe Mouawad <[email protected]> wrote: > Thanks for the fix > Works fine for me > > On Saturday, February 27, 2016, sebb <[email protected]> wrote: > >> On 27 February 2016 at 00:13, Philippe Mouawad >> <[email protected] <javascript:;>> wrote: >> > On Saturday, February 27, 2016, sebb <[email protected] <javascript:;>> >> wrote: >> > >> >> On 26 February 2016 at 18:44, Philippe Mouawad >> >> <[email protected] <javascript:;> <javascript:;>> wrote: >> >> > On Friday, February 26, 2016, sebb <[email protected] <javascript:;> >> <javascript:;>> >> >> wrote: >> >> > >> >> >> On 25 February 2016 at 23:59, sebb <[email protected] <javascript:;> >> <javascript:;> >> >> <javascript:;>> >> >> >> wrote: >> >> >> > On 25 February 2016 at 22:36, Philippe Mouawad >> >> >> > <[email protected] <javascript:;> <javascript:;> >> <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. >> >> >> >> This just means that the new settings must be correctly stored when >> >> the test element is added to the plan. >> >> >> >> > Also sometimes you make a bad choice on default and not being able to >> >> > change it is a problem. >> >> >> >> What we are talking about here is the default meaning for the JMX file >> >> if the setting is not defined in the file. >> >> This must not be changed once established. >> >> >> >> > >> >> > >> >> >> >> >> >> But this does not mean that we cannot change the default for *new* >> >> >> test elements. >> >> > >> >> > Yes but here cookiemanager is not a new element. >> >> >> >> I mean a new element in a Test Plan - i.e. right-click and "add >> >> cookiemanager". >> >> >> >> The GUI can be created with whatever defaults are thought sensible. >> >> >> >> If any field values match the JMX default, they will not be stored, >> >> but if different they will be stored. >> >> >> >> > >> >> >> >> >> >> 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 ? >> >> >> >> If a user creates a Test Plan with policy X, then it should remain >> >> policy X when it is reloaded in future versions of JMeter. >> > >> > >> > it's precisely the problem. >> > Try it: >> > Create test plan with cookie manager having defaults of jmeter 2.13, >> change >> > policy to something different. >> > >> > Open the plan with 3.0, as the default implementation (hc3) was not saved >> > in xml, 3.0 thinks it's the new default and sets policy to hc4 breaking >> > the plan . >> >> Yes, that's exactly the problem that occurs when you change the >> DEFAULT values used in the set/get Property methods used to interface >> with the JMX settings. >> If you revert back to the original values, the problem disappears. >> >> Changing the GUI default needs to be done in the GUI. >> >> > >> > >> >> However when they create a new Test Plan, or add elements to an >> >> existing plan, then we *can* change the default in the GUI. >> >> >> >> > >> >> >> >> >> >> > As above. >> >> >> > >> >> >> >> >> >> >> >> Thanks >> >> >> >> Regards >> >> >> >> Philippe M. >> >> >> >> @philmdot >> >> >> >> >> > >> >> > >> >> > -- >> >> > Cordialement. >> >> > Philippe Mouawad. >> >> >> > >> > >> > -- >> > Cordialement. >> > Philippe Mouawad. >> > > > -- > Cordialement. > Philippe Mouawad.
