>For a response to the second half of your message Actually it isnt clear. It is trivial to write a wrapper that spawns a jmeter process and waits for it to complete (similar to when you run jmeter from ANT ) . the one problem is a distributed setup (but embedding jmeter wouldnt solve that problem anyway). So the question is what more do you need when you want to run jmeter from your application? (i.e. why is it important to run it within the same process as the caller - given that now you are reducing the number of resources that would be available to the jmeter VM)
> but how would JMeter benefit from that It wouldnt , but Im from the use what works for your problem rather than the one size fits all approach. regards deepak On Mon, Jul 25, 2011 at 5:05 AM, _ext van Leeuwen, Paul < [email protected]> wrote: > Apparently I am not the only person who sees the benefit of a more > programmatic interface: I found that some other guy from some other company > already created a feature request some time ago: > https://issues.apache.org/bugzilla/show_bug.cgi?id=50034 > > I guess now I can only wait. If you read this thread and also want a more > programmer-friendly JMeter API, then please consider leaving a comment on > the issue above to make yourself heard. > > With regards to the suggestions made on this email-thread: > > @apc : it seems to me that your logic is from the point of view of JMeter. > I am looking at other frameworks: like when running a large regression test > set on the machine of every developer and some continues integration server > (like Hudson). Some of these tests might use JMeter while others do not. In > such case you just want to be able to add JMeter as a dependency on your > project (having e.g. maven managing the details) and do something like: > JMeter jmeter = new JMeter(); > TestResult result = jmeter.run(outputStreamWithMyJMXFile); > assertTrue(result.isSuccessfull()); > Another example is when defining a broader set of automated tests in > FitNesse. Trying to write fixtures that call JMeter is currently quite a > pain. > > @brian : you seem to understand what I mean and what I am trying to do. > Indeed there are solutions existing to call JMeter in a programmatic way: > the ant plugin you refer to assumes JMeter to be installed in a specific > location. There is also a maven plugin that has a lot of boilerplate code to > initialize JMeter. Both are a bit hacky and unstable on the long term: with > newer versions they may break. That is exactly why I would hope that JMeter > has a native API for its core (which could then be worked on from the GUI or > from other Java code. I am not sure whether the JMeter developers would > consider such. > > @deepak : sure I could decompile the JMeter plugin I was referring to and > move to a JMeter alternative that is more programmers friendly (like > HttpUnit), but how would JMeter benefit from that? Also I still find JMeter > the best tool for our needs: from time to time we will have to record new > test actions and the JMeter GUI is quite helpful there. Also JMeter is a > tool that is already known to the less-technical people in the department, > so I'd rather not switch. For a response to the second half of your message: > please see my response to apc above. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
