jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: About the saving of properties which values have the default ones
Date Sat, 27 Feb 2016 10:51:45 GMT
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
<philippe.mouawad@gmail.com> wrote:
> Thanks for the fix
> Works fine for me
>
> On Saturday, February 27, 2016, sebb <sebbaz@gmail.com> wrote:
>
>> On 27 February 2016 at 00:13, Philippe Mouawad
>> <philippe.mouawad@gmail.com <javascript:;>> wrote:
>> > On Saturday, February 27, 2016, sebb <sebbaz@gmail.com <javascript:;>>
>> wrote:
>> >
>> >> On 26 February 2016 at 18:44, Philippe Mouawad
>> >> <philippe.mouawad@gmail.com <javascript:;> <javascript:;>>
wrote:
>> >> > On Friday, February 26, 2016, sebb <sebbaz@gmail.com <javascript:;>
>> <javascript:;>>
>> >> wrote:
>> >> >
>> >> >> On 25 February 2016 at 23:59, sebb <sebbaz@gmail.com <javascript:;>
>> <javascript:;>
>> >> <javascript:;>>
>> >> >> wrote:
>> >> >> > On 25 February 2016 at 22:36, Philippe Mouawad
>> >> >> > <philippe.mouawad@gmail.com <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.

Mime
View raw message