RE: How should no-op setter methods be filed in Bugzilla?

[Epp, Jeremiah W (Contractor)]

> -Original Message-
> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
> Sent: Monday, November 28, 2016 2:51 PM
> To: dev@jmeter.apache.org
> Subject: RE: How should no-op setter methods be filed in Bugzilla?
>
> The class you mentioned uses an instance variable instead of using
> this.setProperty(...), so I thought that this might be your problem and
> wanted to ask, of the other examples you found, have the same property
> (that is, not using setProperty).

You know, I hadn't thought of that!  That could be a promising lead; I'll
take a closer look and see if I can confirm/deny.

If that _is_ the case, what do you suppose would be the correct approach to
fixing the problem?  IMO, the "obvious" solution is to prefer setProperty()
in setter methods.  But that's both ugly to look at and not enforceable in
code, so it only exists by convention (i.e. still really easy to mess it
up).  I believe it would be more robust and sensible to consider this a bug
in SaveService failing to lower user-facing properties so they can be
included in the output.

>> I've tried.  XStream is kind of obtuse, and I'm still trying to figure
>> out the point where the data structure is lowered to a HashTree that
>> SaveService can work with.  If I knew that, I might be able to _fix_ it.
>
> I would love to hear more about this, when you have something to report
> here.

I wonder if someone else here can point me in the right direction?  Sebb?

Cheers,
Wyatt

Confidentiality Notice: This electronic message transmission, including any 
attachment(s), may contain confidential, proprietary, or privileged information 
from Chemical Abstracts Service ("CAS"), a division of the American Chemical 
Society ("ACS"). If you have received this transmission in error, be advised 
that any disclosure, copying, distribution, or use of the contents of this 
information is strictly prohibited. Please destroy all copies of the message 
and contact the sender immediately by either replying to this message or 
calling 614-447-3600.

RE: How should no-op setter methods be filed in Bugzilla?

[Felix Schumacher]

Am 28. November 2016 20:18:22 MEZ, schrieb "Epp, Jeremiah W (Contractor)" 
:
>Whoops, forgot to address this after my machine was rebooted by a power
>outage and then work got in the way.  Sorry about that.
>
>> -Original Message-
>> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
>> Sent: Tuesday, November 15, 2016 2:51 PM
>> To: dev@jmeter.apache.org
>> Subject: Re: How should no-op setter methods be filed in Bugzilla?
>>
>> Am 14.11.2016 um 20:20 schrieb Epp, Jeremiah W (Contractor):
 -Original Message-
 From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]

 I have attached a test case that models this, with the only
>downside,
 that it works with current trunk.
>>>
>>> Thank you, though I have to admit I'm not sure how to correctly run
>that.
>>> Unfortunately, nor do I really have time to get deep in this problem
>right
>>> now.  The example was really just to show the _class_ of problem
>I've had to
>>> work around. There have been a slew of these.
>>
>> Is this class of problems, those classes, that use instance variables
>for
>> state instead of jmeter-properties?
>
>Beg your pardon?  I was saying its representative of a category of
>similar
>examples that only differ in the class and method name.

The class you mentioned uses an instance variable instead of using 
this.setProperty(...), so I thought that this might be your problem and wanted 
to ask, of the other examples you found, have the same property (that is, not 
using setProperty).

>
>>> Let's try this: if you were going to export those postProcessors in
>your
>>> test to a JMX file on the disk, what would the code look like?
>>
>> Well, if I remember correctly, you are using JMeter in quite some
>> interesting ways, that are not the usual ones. So it may very well
>be,
>> that you find interesting behaviour.
>
>I'd say it's a moderately interesting application at most.  I've only
>had to
>extend one class; 99% of what I have is pretty obvious use of the APIs.
>
>> The only way I save elements is to let JMeter save them and I haven't
>> looked to deeply into that, yet.
>
>I've tried.  XStream is kind of obtuse, and I'm still trying to figure
>out
>the point where the data structure is lowered to a HashTree that
>SaveService
>can work with.  If I knew that, I might be able to _fix_ it.

I would love to hear more about this, when you have something to report here.

Regards,
Felix

>
>Regards,
>Wyatt
>
>Confidentiality Notice: This electronic message transmission, including
>any attachment(s), may contain confidential, proprietary, or privileged
>information from Chemical Abstracts Service ("CAS"), a division of the
>American Chemical Society ("ACS"). If you have received this
>transmission in error, be advised that any disclosure, copying,
>distribution, or use of the contents of this information is strictly
>prohibited. Please destroy all copies of the message and contact the
>sender immediately by either replying to this message or calling
>614-447-3600.

RE: How should no-op setter methods be filed in Bugzilla?

[Epp, Jeremiah W (Contractor)]

Whoops, forgot to address this after my machine was rebooted by a power
outage and then work got in the way.  Sorry about that.

> -Original Message-
> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
> Sent: Tuesday, November 15, 2016 2:51 PM
> To: dev@jmeter.apache.org
> Subject: Re: How should no-op setter methods be filed in Bugzilla?
>
> Am 14.11.2016 um 20:20 schrieb Epp, Jeremiah W (Contractor):
>>> -Original Message-
>>> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
>>>
>>> I have attached a test case that models this, with the only downside,
>>> that it works with current trunk.
>>
>> Thank you, though I have to admit I'm not sure how to correctly run that.
>> Unfortunately, nor do I really have time to get deep in this problem right
>> now.  The example was really just to show the _class_ of problem I've had to
>> work around. There have been a slew of these.
>
> Is this class of problems, those classes, that use instance variables for
> state instead of jmeter-properties?

Beg your pardon?  I was saying its representative of a category of similar
examples that only differ in the class and method name.

>> Let's try this: if you were going to export those postProcessors in your
>> test to a JMX file on the disk, what would the code look like?
>
> Well, if I remember correctly, you are using JMeter in quite some
> interesting ways, that are not the usual ones. So it may very well be,
> that you find interesting behaviour.

I'd say it's a moderately interesting application at most.  I've only had to
extend one class; 99% of what I have is pretty obvious use of the APIs.

> The only way I save elements is to let JMeter save them and I haven't
> looked to deeply into that, yet.

I've tried.  XStream is kind of obtuse, and I'm still trying to figure out
the point where the data structure is lowered to a HashTree that SaveService
can work with.  If I knew that, I might be able to _fix_ it.

Regards,
Wyatt

Confidentiality Notice: This electronic message transmission, including any 
attachment(s), may contain confidential, proprietary, or privileged information 
from Chemical Abstracts Service ("CAS"), a division of the American Chemical 
Society ("ACS"). If you have received this transmission in error, be advised 
that any disclosure, copying, distribution, or use of the contents of this 
information is strictly prohibited. Please destroy all copies of the message 
and contact the sender immediately by either replying to this message or 
calling 614-447-3600.

Re: How should no-op setter methods be filed in Bugzilla?

[Felix Schumacher]

Am 14.11.2016 um 20:20 schrieb Epp, Jeremiah W (Contractor):

-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
Sent: Monday, November 14, 2016 10:11 AM
To: dev@jmeter.apache.org
Subject: Re: How should no-op setter methods be filed in Bugzilla?

I have attached a test case that models this, with the only downside,
that it works with current trunk.

Thank you, though I have to admit I'm not sure how to correctly run that.
Unfortunately, nor do I really have time to get deep in this problem right
now.  The example was really just to show the _class_ of problem I've had to
work around. There have been a slew of these.
Is this class of problems, those classes, that use instance variables 
for state instead of jmeter-properties?




But, looking at the code real quick gives me an idea...

Okay, that does help narrow it down.  Using the getter and setter methods
works fine... at runtime.  But there's something janky in how JMX export is
working.  Whether it's in JMeter or my own code, I'm not really sure, but if
we don't set the actual properties, they don't get saved in the output.

Let's try this: if you were going to export those postProcessors in your
test to a JMX file on the disk, what would the code look like?
Well, if I remember correctly, you are using JMeter in quite some 
interesting ways, that are not the usual ones. So it may very well be, 
that you find interesting behaviour.


The only way I save elements is to let JMeter save them and I haven't 
looked to deeply into that, yet.





Which version of JMeter do you use?

Just vanilla 3.0 (previously, 2.13). 3.1 once it comes out.  Really, there's
nothing special going on here.

Good to know.




If you think the api doesn't work as it should, you could first try to
discuss it here on the mailing list, or if it is really a no-brainer,
submit a bug. It would be superb, if you could provide a test case showing
the error.

I was thinking this was pretty open-and-shut.  It may still be, but that's
less clear. I guess it really depends on what we settle on as the real bug
in this case.  That'll inform how I file it.


Great,
 Felix



Cheers,
Wyatt

Confidentiality Notice: This electronic message transmission, including any attachment(s), may 
contain confidential, proprietary, or privileged information from Chemical Abstracts Service 
("CAS"), a division of the American Chemical Society ("ACS"). If you have 
received this transmission in error, be advised that any disclosure, copying, distribution, or use 
of the contents of this information is strictly prohibited. Please destroy all copies of the 
message and contact the sender immediately by either replying to this message or calling 
614-447-3600.

RE: How should no-op setter methods be filed in Bugzilla?

[Epp, Jeremiah W (Contractor)]

> -Original Message-
> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
> Sent: Monday, November 14, 2016 10:11 AM
> To: dev@jmeter.apache.org
> Subject: Re: How should no-op setter methods be filed in Bugzilla?
>
> I have attached a test case that models this, with the only downside,
> that it works with current trunk.

Thank you, though I have to admit I'm not sure how to correctly run that.
Unfortunately, nor do I really have time to get deep in this problem right
now.  The example was really just to show the _class_ of problem I've had to
work around. There have been a slew of these.

But, looking at the code real quick gives me an idea...

Okay, that does help narrow it down.  Using the getter and setter methods
works fine... at runtime.  But there's something janky in how JMX export is
working.  Whether it's in JMeter or my own code, I'm not really sure, but if
we don't set the actual properties, they don't get saved in the output.

Let's try this: if you were going to export those postProcessors in your
test to a JMX file on the disk, what would the code look like?

> Which version of JMeter do you use?

Just vanilla 3.0 (previously, 2.13). 3.1 once it comes out.  Really, there's
nothing special going on here.

> If you think the api doesn't work as it should, you could first try to
> discuss it here on the mailing list, or if it is really a no-brainer,
> submit a bug. It would be superb, if you could provide a test case showing
> the error.

I was thinking this was pretty open-and-shut.  It may still be, but that's
less clear. I guess it really depends on what we settle on as the real bug
in this case.  That'll inform how I file it.

Cheers,
Wyatt

Confidentiality Notice: This electronic message transmission, including any 
attachment(s), may contain confidential, proprietary, or privileged information 
from Chemical Abstracts Service ("CAS"), a division of the American Chemical 
Society ("ACS"). If you have received this transmission in error, be advised 
that any disclosure, copying, distribution, or use of the contents of this 
information is strictly prohibited. Please destroy all copies of the message 
and contact the sender immediately by either replying to this message or 
calling 614-447-3600.

Re: How should no-op setter methods be filed in Bugzilla?

[Felix Schumacher]

Am 14.11.2016 14:47, schrieb Epp, Jeremiah W (Contractor):
While working on our load automation tooling, I've had to figure out a 
lot
of obscure and relatively undocumented things about the JMeter 
internals.
One of the more bizarre things I've run into is a bunch of setter 
methods
that apparently just don't work, forcing you to use setProperty() in a 
bunch

of places instead.  It's really annoying.

Example:
JSR223PostProcessor jsr = new JSR223PostProcessor();
jsr. setScriptLanguage("beanshell");   // This doesn't actually do 
anything.
jsr. setProperty("scriptLanguage", "beanshell"); // We have to use 
this.


I have attached a test case that models this, with the only downside, 
that it works with current trunk.
Which version of JMeter do you use? And is the test broken with your 
sources?




I realised last Friday (after hitting two more) that I should probably 
be
reporting these, but I wanted to check on the list first about how we 
want
them in Bugzilla.  Should each method have a bug?  Each class?  Should 
there

be a tracking bug for them?  A bz Keyword?  Please advise.


If you think the api doesn't work as it should, you could first try to 
discuss it here on the mailing list, or if it is really a no-brainer, 
submit a bug. It would be superb, if you could provide a test case 
showing the error.


On the scope of the bug. Judge yourself. I prefer to have simple bug 
reports.


Regards,
 Felix



Regards,
Wyatt

Confidentiality Notice: This electronic message transmission,
including any attachment(s), may contain confidential, proprietary, or
privileged information from Chemical Abstracts Service ("CAS"), a
division of the American Chemical Society ("ACS"). If you have
received this transmission in error, be advised that any disclosure,
copying, distribution, or use of the contents of this information is
strictly prohibited. Please destroy all copies of the message and
contact the sender immediately by either replying to this message or
calling 614-447-3600.
package org.apache.jmeter.extractor;

import static org.junit.Assert.assertThat;

import org.apache.jmeter.samplers.SampleResult;
import org.apache.jmeter.threads.JMeterContext;
import org.apache.jmeter.threads.JMeterContextService;
import org.apache.jmeter.threads.JMeterVariables;
import org.hamcrest.CoreMatchers;
import org.junit.Test;

public class JSR223PostProcessorTest {

@Test
public void testGetScriptLanguage() {
JSR223PostProcessor processor = new JSR223PostProcessor();
processor.setScriptLanguage("JavaScript");
assertThat(processor.getScriptLanguage(), 
CoreMatchers.is("JavaScript"));
processor.setScriptLanguage("BeanShell");
assertThat(processor.getScriptLanguage(), CoreMatchers.is("BeanShell"));
}

@Test
public void testProcessDefaultLanguage() throws Exception {
JSR223PostProcessor processor = new JSR223PostProcessor();
processor.setScript("def answer = 1+2+3+5+7+11+13; vars.put('result', 
''+answer)");
processor.setThreadContext(initialContext());
processor.process();
assertThat(processor.getThreadContext().getVariables().get("result"), 
CoreMatchers.is("42"));
}

@Test
public void testProcessJS() throws Exception {
JSR223PostProcessor processor = new JSR223PostProcessor();
processor.setScriptLanguage("JavaScript");
processor.setScript("var answer = 1+2+3+5+7+11+13; vars.put('result', 
''+answer)");
processor.setThreadContext(initialContext());
processor.process();
assertThat(processor.getThreadContext().getVariables().get("result"), 
CoreMatchers.is("42"));
}

private JMeterContext initialContext() {
JMeterContext context = JMeterContextService.getContext();
context.setPreviousResult(new SampleResult());
context.setVariables(new JMeterVariables());
return context;
}

}