Hi Sebb,
Sebb - Would it help JMeter to have this? If so, can you please add ;-)
I can't at present think of a reason why JMeter would need the version
at run-time, because we bundle a known version.
But it might well be useful for other applications, e.g. web applications.
From experience such metadata is not needed every day (like true
mutliple-inheritance etc.), but if you run into a need for it then the
availability appears to be just God sent!
However, it would be nice for JMeter if BSF made it easy to retrieve
the list of registered languages ;-)
That's an interesting suggestion. Currently, BSFManager employs a
HashTable of registered engines (langName->classNameOfEngine) which
could be made available via a static "getRegisteredEngines()" accessor
method. Would that help solve your use case?
Would anyone object to add that static method to BSFManager?
Any other suggestions/ideas/requests?
[I would like to work a bit on the code this coming weekend, mainly to
incorporate the Jira issues/requests, but then it would be also possible
to add the one or other useful functionality.]
---rony
P.S.: Personally, I would like to incorporate ant's nice class that
incorporates all JSR-223/Java6/BSF3 scripting engines into BSF2.4, cf.
<https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/container.script/src/main/java/org/apache/tuscany/container/script/jsr223/JSR223BSFEngine.java>
using the org.apache.bsf package name.
P.P.S.: In addition, I have been thinking of another idea which would
allow JSR-223/Java6/BSF3 to employ BSF2.4 scripting languages,
distributed with BSF2.4.
