On 12 October 2011 18:06, Nico Kruger <[email protected]> wrote: > On 12 October 2011 18:29, sebb <[email protected]> wrote: >> On 12 October 2011 17:06, Nico Kruger <[email protected]> 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)?
No plans at present, but it would probably be sensible to optionally share interpreters, either for a specific sampler (across loops) or a thread. > 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) BSF is likely to continue to be needed for some languages. It might not get as much attention as JSR223, but I see no reason to drop it. > 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. Yes, that needs documenting. > 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: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
