By "reset", if you mean "throw all the stuff in global to get a blank
global", then you can do this:
ScriptContext sc = engine.getContext();
sc.setBindings(engine.createBindings(), ScriptContext.ENGINE_SCOPE);
This will create fresh (ECMAScript) global and makes it as ENGINE_SCOPE
of the default context.
-Sundar
On Sunday 19 July 2015 02:37 AM, Matt Kime wrote:
thanks, this is very helpful.
one issue remains for me - is there a good way to reset the script engines
in a development environment without restarting the whole app?
--matt
On Wed, Jul 15, 2015 at 1:02 PM, Sebastien Deleuze <[email protected]>
wrote:
Hi,
We ended up to use thread-local script engines [1] in Spring 4.2 for
Javascript libraries not designed for concurrency like React or Handlebars.
Based on my initial tests, it works pretty well. The main remaining open
question is about the memory consumption, since it creates one ScriptEngine
instance by thread.
If we see some blocking issues regarding this topic, we may eventually
experiment with a synchronized ScriptEngine pool, but I hope the
thread-local approach will be fine.
Regards,
Sébastien Deleuze
[1] https://jira.spring.io/browse/SPR-13034
On Fri, Jun 5, 2015 at 5:08 PM, Matt Kime <[email protected]> wrote:
I'm curious if any progress has been made on isolating whatever isn't
thread safe about handlebars template execution.
I'm also working on using Handlebars.js inside nashorn however i'm doing a
number of things different. i'm precompiling my templates using
https://github.com/gruntjs/grunt-contrib-handlebars and then compile the
js
functions into cached bytecode.
I haven't checked for threading issues yet but I'm glad i found this
discussion so i know that i should.
