cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Nasty flowscript issue - nailed
Date Tue, 06 Jul 2004 09:35:47 GMT
Gianugo Rabellino wrote:

> We had an interesting night here, dealing with a really nasty  
> flowscript issue  
> ( 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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message