On 12 October 2011 18:29, sebb <seb...@gmail.com> wrote: > On 12 October 2011 17:06, Nico Kruger <nico.kru...@gmail.com> wrote: >> Thanks for the very helpful and quick response. >> >> >> > > BSF is the original scripting language API; JSR223 is the related API > that was added to Java 5/6. > They are fairly similar in scope, but different in API. > > They both support BeanShell and some other languages. > There are some langauges that are only supported by one or the other. > >> Is it sufficient to say that, at the moment, the BeanShell sampler is >> the more advanced/mature of the three? > > Not really. > > However it's older and specific to BeanShell so can use features not > in the BSF/JSR223 APIs. > > BeanShell was added first, then BSF; JSR223 was added with the move to > requiring Java 1.5+. > >> Are the different scripting samplers going to be unified in this >> regard in the future? > > Unified i what regard? >
What I mean is, what are the future plans with regards to the 3 different interpreted language samplers? Except for the specific interpreter-sharing behaviour for the BeanShell sampler, there's not a lot of differences, except as you point out in the specific languages that are supported. BeanShell itself is supported by all 3, jRuby by JSR223 and BSF, same for jython/javascript etc. Are there plans in changing the behaviour of the intepreters for JSR223 and BSF to be the same as BeanShell (so that the interpreter is shared in the same way as with beanshell)? What are the future plans of BSF now that JSR223 and java 1.5 is in the mix? This seems to be the more "future-ready" of the three (support for any language that implement JSR223 is quite a powerful thing) I guess I'm just basically wondering why both JSR223 and BSF are there, seeing as the move to Java 1.5 has been made. I understand the historical/legacy reasons, it just seems like duplicate work to support the same 90% of languages in different places. The fact that the behaviour of the interpreter creation also differs (at least at the moment) was definitely a source of confusion, at least for me. Thanks for clearing that up by the way. >> >>> Or perhaps the TCP Sampler would be a more suitable base. >>> >> >> Another good idea, will I be able to access the TCP sampler from a >> scripting sampler? > > It's the other way round; you have to implemement the appropriate API > which is called by the sampler. > See: > > http://jakarta.apache.org/jmeter/usermanual/component_reference.html#TCP_Sampler > This seems to be the best way forward for us at the moment, at least for our basic socket-testing benchmarks. Seems to fit our current needs quite well. Back to basics :) I really do appreciate the power of jMeter, the scripting possibilities really are enormous. Very helpful mailing list as well :) Thanks for your help. --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
