Global context

[hs-lsong]

JinJava can be a singleton and shared by multiple threads. The JinJava rendering context is scoped, but the root of the context -- the global context -- is shared. However, the context should not be shared, especially they can be modified during the rendering. To alleviate the issue,

1. we add a read only accessor, jinjava.getGlobalContextReadOnly(),
2. proxy the registering functions, so that a caller does not have to access the globalContext directly.
3. make a copy of the global context as the root of scoped context for each rendering.

Drawback is once the JinJava's renderForResult is started, updating the global content (registering new filter, etc) has no effect. It might actually be desired.

[mattcoley]

Makes sense, can we branch deploy the renderer and run a diff test to see if this causes any issues?

[boulter]

I'm not sure you can dynamically register new functions or filters. I believe that's why the list of disabled features had to be implemented separately.

[boulter]

Suggested change

	public Context getGlobalContextReadOnly() {
	public Context getGlobalContextCopy() {

[hs-lsong]

I used to use getGlobalContextCopy, thought the readOnly one is better :).

[Joeoh]

Thanks for this. Looks like it will resolve the issue I introduced here. Was that your intention or did I just get lucky here?

I was also going to introduce a flag on Context that would identify it as the global. Not sure if you might consider that useful here so we can easily avoid adding to the context if we know its the global one.

[Joeoh]

Created PR to add global context flag to this: #448

[Joeoh]

Do you plan on merging this soon?

[hs-lsong]

The branch deploy was good. Planing to merge early next week. I wanted to do a bit more debugging before we stop sharing the global context.

[Joeoh]

Sounds good! I'll wait for your changes before merging mine. They give me an extra layer of safety for my changes.