jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Epp, Jeremiah W (Contractor)" <>
Subject RE: JMeter DSL discussion
Date Wed, 10 Aug 2016 18:55:13 GMT
> -----Original Message-----
> From: Vladimir Sitnikov []
> Sent: Wednesday, August 10, 2016 2:10 PM
> To:
> Subject: Re: JMeter DSL discussion
>> Hang on, why would you develop your DSL in a different language from what
>> JMeter itself is actually written in?  This wold seem to  add an entire
>> new toolchain to the build process.
> Can you clarify what you mean by " different language from what JMeter
> itself is actually written in"?
> Do you suggest we should use java as a language to store JMeter test
> plans?  I'm afraid that won't fly high.

I thought he was suggesting implementing the language with Groovy, not using
Groovy _as_ the language.  And no, I'm not suggesting Java would work
better.  Quite the opposite, in fact.

The entire point of a Domain Specific Langauge is to have precise control
over what you can and cannot do (semantics) and how it looks when written
out (syntax).  It's a form of abstraction.

>>> - how to express what today we can do through JSR223 languages which
>>> might be the most complex think to translate
>> Is this really an issue?  This seems orthogonal to the goal of creating a
>> language to describe _test plans_ themselves.  As long as this DSL has a
>> way to express the JSR223 sampler, saving the actual code that goes in it
>> should go without saying.
> Jeremiah, you are missing a point here.  Philippe means: "currently we
> have to use JDS232 samples to workaround limitations of JMeter test plan
> language".  For instance, there is no support for "arrays" in the
> samplers, so one has to use JSR232 kind of scripts to work with arrays.
> So, the quesion is "how to introduce control flow and data processing into
> the DSL itself". Does it make things more clear?

That does clarify, thank you.

So the issue here is the current test plan implementation lacks important
syntax and semantics for end users.  There are workarounds, but they are
kludgy and nontrivial.  This is important information for designing a DSL.

With that understanding, though, I'm somewhat worried that the actual
internal representation of a test plan is in question. I suspect changing
_that_ would be a considerable engineering effort.

Before we take this line of thought any further, I think the actual desired
semantics of this DSL need to be hammered out.  That is, what do people
explicitly _need_ to be able to do?


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