ScriptContext.ENGINE_SCOPE is set to be wrapper over Nashorn's Global
object. So, from current ScriptContext instance, ENGINE_SCOPE bindings
is fetched and set to be current Nashorn Global instance -
(Context.setGlobal call). And reset global after eval as you mentioned.
ScriptContext.GLOBAL_
Hi, I'm still working on this with Tobias.
Our current understanding of what happens is as follows:
When invocation or evaluation is requested on a NashornScriptEngine, it
will:
1. Fetch its current context (protected AbstractScriptEngine member field)
scope: ScriptContext.ENGINE_SCOPE
2. Set this
Hi Jim,
this example shows it pretty well:
https://gist.github.com/tobsch/6026942
as the script itself is very simple and does nothing special. It's only its
invocation or doPrivileged to be precise.
This is the profiler output:
Any ideas?
Best,
Tobias
Am 17.07.2013 um 18:23 schrieb Jim
Tobias,
Would you send some more detailed code snippets (or gist link)?
Cheers,
-- Jim
On 2013-07-17, at 1:35 PM, Tobias Schlottke wrote:
> Hi Jim,
>
> sounds pretty reasonable to me.
> I still have the problem that I want to return something in run() though, so
> this renders a bit more co
Hi Jim,
sounds pretty reasonable to me.
I still have the problem that I want to return something in run() though, so
this renders a bit more complicated.
I understand that you have to check security once but I don't really understand
why in my case because the object should not have changed.
Do
Tobias,
We'll look into removing the doPrivileged on first entry (security is checked
elsewhere), but we need to do a security assessment before proceeding.
That said, I would recommend as a best practice to use a per-thread JavaScript
loop instead, to avoid such issues. I generally use a
jav
Hi there,
I've built a small case where I evaluate a compiled script equipped with a
custom bindings.
The script is equipped with some variables and and compiled like this:
engine.put("shopId", "test");
runner = (Bindings)
engine.compile(ad.getCondition_script().getCode()).eval();
