DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348 Caching problem with XSP, XSL and cocoon pseudo protocol Summary: Caching problem with XSP, XSL and cocoon pseudo protocol Product: Cocoon 2 Version: Current CVS Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: sitemap components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Several cocoon users have reported a caching problem when using cocoon: pseudo protocol with ServerPagesGenerator. Here's an example pipeline: <map:pipeline type="noncaching"> <map:match pattern="foo"> <map:generate type="serverpages" src="cocoon:/bar"/> <map:serialize type="html"/> </map:match> <map:match pattern="bar"> <map:generate src="foobar.xml"/> <map:transform src="XSLwithXSP.xsl"/> <map:serialize type="xml"/> </map:match> </map:pipeline> The XSL page (XSLwithXSP.xsl) is used to extend the original XML page (foobar.xml) with XSP instructions (ESQL etc.), and the result is fed to the ServerPagesGenerator (resource "foo") using "cocoon:" pseudo protocol. Calling "bar" results to an updated page. No problem here. But calling "foo" always results to a cached page. So it seems that the Java code generated by the ServerPagesGenerator is not updated! The only thing that seems to help is to remove the work-dir and restart Tomcat. Doing this after every change is very frustrating and slow. Here's some experiments on the subject: http://www.mail-archive.com/cocoon-users@;xml.apache.org/msg19064.html If any of you developers can find and fix the problem, please do. I consider this as a major blocker in the framework. This is because pipelines like the example above can be used to create very flexible and general web applications. (For example, a complete database management system with one descriptor file). Thanks A LOT in advance, Tuomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
