On Saturday, February 27, 2016, sebb <[email protected]> wrote: > There are still more fixes to be applied; looks like some unit tests > were 'fixed' to avoid test failures.
i don't think so, they are due to cookie new rfc. Please point to the one you think I "badly fixed" > > On 27 February 2016 at 10:23, Philippe Mouawad > <[email protected] <javascript:;>> wrote: > > Thanks for the fix > > Works fine for me > > > > On Saturday, February 27, 2016, sebb <[email protected] <javascript:;>> > wrote: > > > >> On 27 February 2016 at 00:13, Philippe Mouawad > >> <[email protected] <javascript:;> <javascript:;>> wrote: > >> > On Saturday, February 27, 2016, sebb <[email protected] <javascript:;> > <javascript:;>> > >> wrote: > >> > > >> >> On 26 February 2016 at 18:44, Philippe Mouawad > >> >> <[email protected] <javascript:;> <javascript:;> > <javascript:;>> wrote: > >> >> > On Friday, February 26, 2016, sebb <[email protected] > <javascript:;> <javascript:;> > >> <javascript:;>> > >> >> wrote: > >> >> > > >> >> >> On 25 February 2016 at 23:59, sebb <[email protected] > <javascript:;> <javascript:;> > >> <javascript:;> > >> >> <javascript:;>> > >> >> >> wrote: > >> >> >> > On 25 February 2016 at 22:36, Philippe Mouawad > >> >> >> > <[email protected] <javascript:;> <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. > -- Cordialement. Philippe Mouawad.
