New fields/changed defaults cause earlier test plans to be marked as changed (bug 59173)

[Philippe Mouawad <ph...@gmail.com>]

Hello,

Sebb opened a bug 59173 reporting a problem of "spurious" save message when
4 elements are selected.


I fixed 1/4 of these.
The problem is that fixing the 3/4 other "issues" is if not impossible not
simple at all:

1/ Access Log Sampler:

AFAIU (but I may not understand well) , nothing seems to be available
for this case when using
XXXXBeanInfo


2/ JMS Publisher:

There was a mistake made in previous release (my fault) when adding 2
properties.

Fixing the bug makes code ugly. I personally prefer the spurious
message vs the ugly code.



3/ Backend Listener :
- A new parameter was added , AFAIK (but I may be wrong) we have
nothing currently to handle this case. But it does not hurt me, as
JMeter 3.0 adds a new parameter, the test plan really changed.
- This informs indirectly the user of this new property.


For 1/ and 3/, maybe we can implement it in a future release but I
don't think it should be blocker for the 3.0 release.


Regards
Philippe

Re: New fields/changed defaults cause earlier test plans to be marked as changed (bug 59173)

[sebb <se...@gmail.com>]

On 18 March 2016 at 22:10, Philippe Mouawad <ph...@gmail.com> wrote:
> On Fri, Mar 18, 2016 at 11:02 PM, sebb <se...@gmail.com> wrote:
>
>> On 18 March 2016 at 21:46, Philippe Mouawad <ph...@gmail.com>
>> wrote:
>> > Hello,
>> >
>> > Sebb opened a bug 59173 reporting a problem of "spurious" save message
>> when
>> > 4 elements are selected.
>> >
>> >
>> > I fixed 1/4 of these.
>> > The problem is that fixing the 3/4 other "issues" is if not impossible
>> not
>> > simple at all:
>> >
>> > 1/ Access Log Sampler:
>> >
>> > AFAIU (but I may not understand well) , nothing seems to be available
>> > for this case when using
>> > XXXXBeanInfo
>>
>> True, but it could be added fairly easily.
>>
> Great news. So can you add it or explain it to me ?

Looking at it now.

>>
>> >
>> > 2/ JMS Publisher:
>> >
>> > There was a mistake made in previous release (my fault) when adding 2
>> > properties.
>> >
>> > Fixing the bug makes code ugly. I personally prefer the spurious
>> > message vs the ugly code.
>>
>> Yes, but you are a developer who understands why this message occurs.
>>
>> I am too, but I still find it very disconcerting when I'm told my test
>> plan has been changed without having done anything.
>>
>>
> I tried to find a clean fix, I didn't.

What fix did you find?

>
>> >
>> >
>> > 3/ Backend Listener :
>> > - A new parameter was added , AFAIK (but I may be wrong) we have
>> > nothing currently to handle this case. But it does not hurt me, as
>> > JMeter 3.0 adds a new parameter, the test plan really changed.
>>
>> But this is precisely the issue.
>> The test plan from 2.13 behaves exactly the same in 3.0 (if not,
>> there's another bug).
>> The new parameter defaults to false, so if it is missing the test
>> behaves as before.
>>
>> > - This informs indirectly the user of this new property.
>>
>> But the new property does not change the test unless it is changed
>> from the default, so it's really not helpful.
>>
>> Imagine if your favourite word processor behaved like this.
>>
>> You write a document and save it.
>> Later on you open it in a new version of the program; you don't make
>> any changes.
>> Yet when you close the document the word processor asks you to save it.
>> That would be very disconcerting.
>> You would wonder if you had changed anything by mistake.
>>
>
> It's true.
> But we can add it as a known issue and fix it in next release.

No, we cannot.

>>
>> >
>> > For 1/ and 3/, maybe we can implement it in a future release but I
>> > don't think it should be blocker for the 3.0 release.
>>
>> We have either got to do it now or not at all.
>> Otherwise we have the same issue for plans created in 3.0.
>>
>
> No as we would have fixed it in 3.1.

Not possible.

If we don't fix 3.0, then it will save the extra properties.

If we do fix 3.1 so its test plans agree with 2.13, then its test
plans won't agree with 3.0.

In other words:

We start with TP2.13 != TP3.0

If we make TP3.1 == TP2.13 that implies TP3.1 != TP3.0.

The problem has to be fixed now, or not at all for these particular
test element properties.

Going forward, we need to make sure that we don't cause the problem
again for other test elements.

>> >
>> > Regards
>> > Philippe
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: New fields/changed defaults cause earlier test plans to be marked as changed (bug 59173)

[Philippe Mouawad <ph...@gmail.com>]

On Fri, Mar 18, 2016 at 11:02 PM, sebb <se...@gmail.com> wrote:

> On 18 March 2016 at 21:46, Philippe Mouawad <ph...@gmail.com>
> wrote:
> > Hello,
> >
> > Sebb opened a bug 59173 reporting a problem of "spurious" save message
> when
> > 4 elements are selected.
> >
> >
> > I fixed 1/4 of these.
> > The problem is that fixing the 3/4 other "issues" is if not impossible
> not
> > simple at all:
> >
> > 1/ Access Log Sampler:
> >
> > AFAIU (but I may not understand well) , nothing seems to be available
> > for this case when using
> > XXXXBeanInfo
>
> True, but it could be added fairly easily.
>
Great news. So can you add it or explain it to me ?

>
> >
> > 2/ JMS Publisher:
> >
> > There was a mistake made in previous release (my fault) when adding 2
> > properties.
> >
> > Fixing the bug makes code ugly. I personally prefer the spurious
> > message vs the ugly code.
>
> Yes, but you are a developer who understands why this message occurs.
>
> I am too, but I still find it very disconcerting when I'm told my test
> plan has been changed without having done anything.
>
>
I tried to find a clean fix, I didn't.


> >
> >
> > 3/ Backend Listener :
> > - A new parameter was added , AFAIK (but I may be wrong) we have
> > nothing currently to handle this case. But it does not hurt me, as
> > JMeter 3.0 adds a new parameter, the test plan really changed.
>
> But this is precisely the issue.
> The test plan from 2.13 behaves exactly the same in 3.0 (if not,
> there's another bug).
> The new parameter defaults to false, so if it is missing the test
> behaves as before.
>
> > - This informs indirectly the user of this new property.
>
> But the new property does not change the test unless it is changed
> from the default, so it's really not helpful.
>
> Imagine if your favourite word processor behaved like this.
>
> You write a document and save it.
> Later on you open it in a new version of the program; you don't make
> any changes.
> Yet when you close the document the word processor asks you to save it.
> That would be very disconcerting.
> You would wonder if you had changed anything by mistake.
>

It's true.
But we can add it as a known issue and fix it in next release.

>
> >
> > For 1/ and 3/, maybe we can implement it in a future release but I
> > don't think it should be blocker for the 3.0 release.
>
> We have either got to do it now or not at all.
> Otherwise we have the same issue for plans created in 3.0.
>

No as we would have fixed it in 3.1.

>
> >
> > Regards
> > Philippe
>



-- 
Cordialement.
Philippe Mouawad.

Re: New fields/changed defaults cause earlier test plans to be marked as changed (bug 59173)

[sebb <se...@gmail.com>]

On 18 March 2016 at 21:46, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello,
>
> Sebb opened a bug 59173 reporting a problem of "spurious" save message when
> 4 elements are selected.
>
>
> I fixed 1/4 of these.
> The problem is that fixing the 3/4 other "issues" is if not impossible not
> simple at all:
>
> 1/ Access Log Sampler:
>
> AFAIU (but I may not understand well) , nothing seems to be available
> for this case when using
> XXXXBeanInfo

True, but it could be added fairly easily.

>
> 2/ JMS Publisher:
>
> There was a mistake made in previous release (my fault) when adding 2
> properties.
>
> Fixing the bug makes code ugly. I personally prefer the spurious
> message vs the ugly code.

Yes, but you are a developer who understands why this message occurs.

I am too, but I still find it very disconcerting when I'm told my test
plan has been changed without having done anything.

>
>
> 3/ Backend Listener :
> - A new parameter was added , AFAIK (but I may be wrong) we have
> nothing currently to handle this case. But it does not hurt me, as
> JMeter 3.0 adds a new parameter, the test plan really changed.

But this is precisely the issue.
The test plan from 2.13 behaves exactly the same in 3.0 (if not,
there's another bug).
The new parameter defaults to false, so if it is missing the test
behaves as before.

> - This informs indirectly the user of this new property.

But the new property does not change the test unless it is changed
from the default, so it's really not helpful.

Imagine if your favourite word processor behaved like this.

You write a document and save it.
Later on you open it in a new version of the program; you don't make
any changes.
Yet when you close the document the word processor asks you to save it.
That would be very disconcerting.
You would wonder if you had changed anything by mistake.

>
> For 1/ and 3/, maybe we can implement it in a future release but I
> don't think it should be blocker for the 3.0 release.

We have either got to do it now or not at all.
Otherwise we have the same issue for plans created in 3.0.

>
> Regards
> Philippe