After some investigation in this problem, I found a difference in the
servlet engines.
The CocoonServlet.getCocoon() method checks the pathInfo of the request:
<<code snip>>
private synchronized Cocoon getCocoon(final String pathInfo, final String reloadParam)
{
if (this.cocoon != null) {
if (this.cocoon.modifiedSince(this.creationTime)) {
log.info("Configuration changed reload attempt");
this.createCocoon();
return this.cocoon;
!!TEST!! } else if ((pathInfo == null) && (reloadParam != null)) {
log.info("Forced reload attempt");
this.createCocoon();
return this.cocoon;
}
!!TEST!! } else if ((pathInfo == null) && (reloadParam != null)) {
log.info("Invalid configurations reload");
this.createCocoon();
return this.cocoon;
}
return this.cocoon;
}
<<end code snip>>
So the cocoon-reload parameter does only take effect if the pathInfo is null. Using
Tomcat 3.2.1 the pathInfo is always null, so the cocoon-reload works fine.
Using e.g. Bea 5.1 the pathInfo is never null but the name of the requested resource,
so cocoon-reload never works!
Why is this test of the pathInfo here? What is the reason for this test?
Carsten
> Matthew Langham wrote:
>
> Hi,
>
> why is it that I need to enter "cocoon-reload%3Dtrue" in my Netscape
> browser
> and "cocoon-reload=true" in IE to get Cocoon to actually recompile the
> sitemap?
>
> Any ideas?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
|