Christopher Oliver wrote:
What defines an application in Cocoon.
Some (not necessarily root) sitemap and all of its subsitemaps can be seen as one application. Sub-sitemaps can be seen as sub-applications...
For example, does each get a separate class loader? Is there a relationship to sitemaps?
Each sitemap gets own ComponentManager which is "component loader", COP (kind-of) equivalence of class loader. This component manager is configured in such a way that it inherits all components from the parent sitemap (SitemapLanguage.java:139)
...
What I'm trying to accomplish here is to share code between users (meaning we don't have to duplicate immutable objects like scripts, thereby saving memory).
Perhaps you can help by explaining how and when instances of JavaScriptInterpreter get created. Is it per sitemap?
Right now I think yes, InterpreterSelector (which is for some reason bound to Interpreter.ROLE instead of Interpreter.ROLE + "Selector") is created for every sitemap - means that it will create instances of Interpreters one per sitemap per language (currently JavaScript only).
With Rhino, script variables are stored in a "scope" object - which must be created on a per user basis. This is the "thrScope" variable you see in JavaScriptInterpreter.java. However, it's possible to share the built-in JavaScript objects, like String, Number, etc. as well as scripts loaded by the sitemap (system.js, etc) since these are immutable objects, among all the thrScope's. This shared scope is the "scope" field in JavaScriptInterpreter.java.
<snip/>
I only want to compile and execute the set of scripts that apply to a specific application. I don't want them shared between different applications. I think I remember Ovidiu saying that each (sub-)sitemap should represent a single application. Does that make sense? If so, would each one its own instance of JavaScriptInterpreter?
I would suggest behaviour similar to the rest of sitemap components: flows defined in parent sitemap should be available in the subsitemaps. Is it possible from JavaScript POV - hierarchical organization of scopes?
Also, is it possible (from JavaScript POV) to have single place (per Cocoon instance) to store / cache / share all pre-compiled JavaScripts? (See JSGenerator.java:98 - currently every instance of Generator will have own instance of Script)
Vadim
