On Aug 5, 3:57 pm, ynniv <[EMAIL PROTECTED]> wrote: > When executing JavaScript from the shell (java -jar js.sh), there is a > Context associated with the current thread. I have a custom Context > that is my security / runaway script barrier, and I'd like to execute > random user JavaScript inside this context. If I use > MyContextFactory.call(), it reuses the existing standard Context > instead of associating a new MyContext with the thread. In this > situation, it would be nice to have a stack of contexts that could be > pushed and popped appropriately. > > Looking at the implementation of Context and ContextFactory, it seems > as though the Context / Thread relationship is deliberately enforced. > Calling MyContext.enter() does nothing, as does Context.call(new > MyContextFactory(), ...). My question is, is this because no one has > needed to nest mixed Context implementations in the same thread, or > was this considered but thrown out due to some subtlety that isn't > currently obvious?
You're right that there should be a 1:1 relationship between Threads and Contexts. The reason for this is so that Rhino runtime information stored in the Context can be maintained across a mixture of Java and JavaScript stack frames. --N _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
