Gianugo Rabellino wrote:
We had an interesting night here, dealing with a really nasty flowscript issue (http://marc.theaimsgroup.com/?t=108798488500001&r=1&w=2). Thanks to the precious help of Jerm, Andrew and Paul Russell, our small hackaton seemed to be successful in at least nailing the issue.
So, there you go: you have different sitemaps, dealing with different flowscripts each BUT all residing in the same directory and mounted using uri-prefix as follows:
<map:mount src="something.xmap" uri-prefix="something" check-reloads="true"/>
<map:mount src="else.xmap" uri-prefix="else" check-reloads="true"/>
BTW, this is "check-reload" (singular), but as it defaults to true, you can safely remove it everywhere ;-)
(BTW, we discussed this already, I really consider this a useless feature).
In that case, FOM_JavaScriptInterpreter screws up because of scope handling: scopes are kept in memory and indexed using a string coming from the internal getSitemapPath() function call which, a bit naively, is as follows:
private String getSitemapPath() throws Exception { Source src = this.sourceresolver.resolveURI("."); try { return src.getURI(); } finally { this.sourceresolver.release(src); } }
Now, whether you ask for /url /something/url or /else/url, that method will always return file://$COCOON_HOME/build/webapp/. This means that the list of available functions will always point to the first set of scripts being evaluated, and on your subsequent requests to seemingly different URLs you get a nice function not found error.
I changed that to
private String getSitemapPath() throws Exception {
return ObjectModelHelper.getRequest(
EnvironmentHelper.getCurrentEnvironment().getObjectModel()).getSitemapUR I();
}
Aargh! You should absolutely avoid to use the very-internal-and-private EnvironmentHelper class! ContextHelper is your friend ;-)
but being a freshman on Cocoon flow internals, I'm afraid this is going to introduce a nasty set of regressions. Can anyone more knowleadgeable verify the problem and possibly provide a more clever solution?
That won't solve the problem since getSitemapURI will return a different result for different request URIs within the same sitemap. This means you will loose the scope between requests to different URIs.
This is a tricky problem as the scope should actually be attached to the Processor instance, since you have here several Processors attached to the same URI prefix.
There is a solution, though: there's a different FlowIntepreter for each Processor instance (they are SingleThreaded), and so each interpreter instance could produce a unique identifier and use it as the result of getSitemapPath (which should therefore be renamed).
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
