On 12 October 2011 17:06, Nico Kruger <nico.kru...@gmail.com> wrote: > Thanks for the very helpful and quick response. > > > > On 12 October 2011 17:30, sebb <seb...@gmail.com> wrote: >> On 12 October 2011 16:03, Nico Kruger <nico.kru...@gmail.com> wrote: >>> Hi there >>> ...SNIP.... >> >> No, the BSF samples currently each use their own BSF Manager and >> interpreter - it is not currently shared. >> >> Same for JSR223 currently. >> >> It's only the BeanShell sampler that re-uses the interpreter. >> > > Could you perhaps elaborate on the difference betweens JSR223 and BSF? > What are the advantages/disadvantages of each, because functionally > they look pretty similair for the untrained eye. In fact, I was > definitely confused about the differences between the three - I was > under the impression that BeanShell is just a different "language" you > choose inside the BSF sampler.
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? >> >> Work-rounds: >> - use BeanShell > > I would like it if we could get away with jRuby instead of switching > to BeanShell. We have a lot of already existing jRuby code that > excercises the system from the outside which we use in cucumber-jvm > for example that I would like to re-use. > >> - create and manage the interpreter yourself - if you use the >> interpreter to create an interpreter rather than a socket, it may be >> possible to invoke the saved interpreter. >> > > Interesting idea, will have a look at this. > >> 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 > > Again, thanks for your insights. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org > For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
