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.
