On Fri, Aug 12, 2016 at 5:10 PM, Epp, Jeremiah W (Contractor) <[email protected]> wrote:
> > -----Original Message----- > > From: Philippe Mouawad [mailto:[email protected]] > > Sent: Wednesday, August 10, 2016 4:00 PM > > To: [email protected] > > 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] https://bz.apache.org/bugzilla/show_bug.cgi?id=57305 > > 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. > > -- Cordialement. Philippe Mouawad.
