Data corruption with Nashorn + Handlebars and concurrent requests

[Sebastien Deleuze]

I am updating my Spring + Nashorn talk and the related sample applications,
and I am wondering if in the Nashorn version provided with java 8u60 there
is a better/easier way to convert a Java Map<String, Object> instance into
a real JSON Object (with Iterable elements being converted to real JSON
arrays)?

Currently I am doing that:

    // Create a real JSON Object from the model Map
    var data = {};
    for (var k in model) {
        // Convert Java Iterable and List to real JSON arrays
        if (model[k] instanceof Java.type("java.lang.Iterable")) {
            data[k] = Java.from(model[k]);
        } else {
            data[k] = model[k];
        }
    }

Any thoughts?

On Mon, Jul 20, 2015 at 5:09 AM, A. Sundararajan <
sundararajan.athijegannathan at oracle.com> wrote:

> 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 <sdeleuze at pivotal.io>
>> 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 <mattk at meetup.com> 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.
>>>>
>>>>
>>>
>