jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <>
Subject Re: How should no-op setter methods be filed in Bugzilla?
Date Mon, 14 Nov 2016 15:10:56 GMT
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 

> 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 


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

View raw message