jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: JMeter DSL discussion
Date Fri, 12 Aug 2016 19:18:52 GMT
On Fri, Aug 12, 2016 at 5:10 PM, Epp, Jeremiah W (Contractor) <>

> > -----Original Message-----
> > From: Philippe Mouawad []
> > Sent: Wednesday, August 10, 2016 4:00 PM
> > To:
> > Subject: Re: JMeter DSL discussion
> >
> > First thanks for having in mind to contribute a non gui recorder,
> Don't thank me yet; legal's giving me hell over this. :(
> > by the way what is the use case ?
> What is the use case for a recorder that can be started without a GUI?
> Well, recording from continuous integration is ours, and it's only because
> of that that we can use JMeter at all.
> There's also the ability to use a remote machine as the recording proxy,
> though it doesn't work without some sort of display server because of the
> ProxyControl's dependency on GuiPackage [0] -- we've been xvfb-run to give
> it the illusion of a screen, but that's an ugly hack no one likes.

Why not provide a patch then ? I'll be happy to review it and commit it
Did you test the patch that was provided ? Does it work ?

> > Since I started writing JMeter plans, I have always had to write some
> part
> > of it (correlation part) in JSR223+Groovy.
> Interesting!  I'd actually be curious what that looks like.  We've been
> toying with the idea of writing a delta-based auto-correlation tool to
> reduce the special case tools in new products, but that takes time.
> And is complex.
But it would be great in JMeter.
I'd be happy to help you on this.

> You know how it is.
> > Although over the years the volume of custom code tends to drop,  I doubt
> > it will be ever possible to express in a DSL all the possibilities.
> Maybe it won't be able to get _everything_-- needs change over time, after
> all.  But I think it could get close to 99.9%.  And there's nothing keeping
> us from adding features if they happen to be needed later.
> > But what Vladimir has in mind is maybe to use a language (Groovy or other
> > for example) and write in it a DSL for JMeter, in that case what I used
> to
> > do with JSR223 might be possible with this language.
> Thinking about this a bit more, I can see how there may be some merit to a
> TestPlan API that lets you write test plans entirely in code.  But that's a
> separate idea, really.

Yes very interesting idea

> For what it's worth, I strongly recommend _against_
> using a full programming language as your DSL.  That's sort of the opposite
> of "domain specific". *g*

Did you look at groovy dsls ?

> > But I am afraid it's a breaking change as he wrote it, I don't know how
> we
> > would be able to handle backward compatibility and Gui compat.  And using
> > the GUI a lot (for example currently in a load testing mission) , I am
> > happy to see that my productivity has even more increased with the new
> > features. I am now definitely convinced that it is very useful.
> IMO, one aspect of this work should be some refactoring to decouple
> "JMeter,
> the graphical test IDE" from "JMeter, the load execution engine".
> This isn't to say the GUI is bad or should be abandoned; far from it!  It's
> very important!
> Tooling matters!
> ...But I've hit a number of snags when trying to write my proxy that where
> the underlying model depends unneccessarily on GUI components.
> There are abstraction leaks.
> Regards,
> Wyatt
> [0]
> 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.

Philippe Mouawad.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message