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 00:46:05 GMT
On 27 February 2016 at 00:13, Philippe Mouawad
<philippe.mouawad@gmail.com> wrote:
> On Saturday, February 27, 2016, sebb <sebbaz@gmail.com> wrote:
>
>> On 26 February 2016 at 18:44, Philippe Mouawad
>> <philippe.mouawad@gmail.com <javascript:;>> wrote:
>> > On Friday, February 26, 2016, sebb <sebbaz@gmail.com <javascript:;>>
>> wrote:
>> >
>> >> On 25 February 2016 at 23:59, sebb <sebbaz@gmail.com <javascript:;>
>> <javascript:;>>
>> >> wrote:
>> >> > On 25 February 2016 at 22:36, Philippe Mouawad
>> >> > <philippe.mouawad@gmail.com <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.

Mime
View raw message