You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by "Epp, Jeremiah W (Contractor)" <je...@cas.org> on 2016/11/14 13:47:46 UTC
How should no-op setter methods be filed in Bugzilla?
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 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.
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?
Posted by "Epp, Jeremiah W (Contractor)" <je...@cas.org>.
> -----Original Message-----
> From: Felix Schumacher [mailto:felix.schumacher@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?
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 28. November 2016 20:18:22 MEZ, schrieb "Epp, Jeremiah W (Contractor)" <je...@cas.org>:
>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.schumacher@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.schumacher@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?
Posted by "Epp, Jeremiah W (Contractor)" <je...@cas.org>.
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.schumacher@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.schumacher@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?
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 14.11.2016 um 20:20 schrieb Epp, Jeremiah W (Contractor):
>> -----Original Message-----
>> From: Felix Schumacher [mailto:felix.schumacher@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?
Posted by "Epp, Jeremiah W (Contractor)" <je...@cas.org>.
> -----Original Message-----
> From: Felix Schumacher [mailto:felix.schumacher@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?
Posted by Felix Schumacher <fe...@internetallee.de>.
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.