> -----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.
