Data corruption with Nashorn + Handlebars and concurrent requests

[Sundararajan Athijegannathan]

Hi,

No, there is no direct way to convert a Java Map to a real JSON object. 
You've to do conversion as you hinted.

-Sundar

On 9/9/2015 2:43 PM, Sebastien Deleuze wrote:
> 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 
> <mailto: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 <mailto: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 <mailto: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.
>
>
>
>