RE: Not caching pages with continuations (was:...where is 304?)
Hello, Ard Schrijvers wrote: snip/ This is actually almost the same hack we used, but instead of a transformer a selector, and if some value set in flowscript, an action to set headers. Because we are outsourcing/other parties using our best practices, and I did not want them to have to think about setting things in flowscript like sessions and values to indicate caching headers, I chose to put it in the black box transformer, which handles it. Of course, also kind of a hack, because users aren't really aware of it (certainly because i did not want another sax transformer, so I did add it to the StripNameSpaceTransformer which is by default used by us in front of the serializer. But it does more then its name suggests, and therefor, it is hacky ofcourse. But...at least nobody has to think about it :-) ). I wondered if there was a solid nonhacky solution to the issue If it's for CForms, we can add the setting of no-cache headers in Form.js since it's very unlikely that a form pipeline will be cacheable. Think we tried similar things (in flowscript), but we found the problem Bertrand also faced about the fact, that you have to set the headers on the pipeline the serializer is used from (but all requests for example arrive at a catch all matcher, which does not know wether it includes a form or not). Do you think you can set it globally for the request in Form.js? I tried directly manipulating the HttpServletResponse, but obviously, this resulted in correct behavior on the first request, but consecutive cached responses did not have this direct HttpServletResponse manipulation, so this implied uncacheable pipelines in cocoon, which of course, I did not want either. But, I am curious about a possible solution Ard Also, for other flowscripts there could be a parameter on the map:flow instruction stating the flowscript engine has to always set the no-cache headers. Sylvain -- Sylvain Wallez - http://bluxte.net
RE: FW: HTTPD mod_cache HttpCacheAction: where is 304?
Hello, Ard Schrijvers wrote: is there any best practice to have cforms in urls you do not know on beforehand, with continuations? Continuation is just randomly generated token, unique to each user interaction (like as session Id). Even if it is cached, even if GET is used as a form method, next form submit will request URL with different (not cached yet) continuation. (I believe continuation ID is always unique). Think you are slightly missing the point: it is not about the submitting of the form, it is about the form itself. Suppose, we have a link, like /form/query.html. Now this for has a CForms form, with a continuation id, either in an input element or in the action. Not the submit is the problem, but the fact that /form/query.html is cached by mod_cache (not, we do not know on beforehand which urls are forms, so we can not tell mod_cache this). Then, mod_cache delivers forms with the same continuation ids for example for 10 minutes, but only the first one to submit will submit a valid continuation. Therefor, from CForms on generation, you want to set globally on the response, the Pragma and Cache-Control header to no-cache (and in load balanced environment, enforce a sticky session) Ard We are talking here about GET methods in general, not about HTTPD... Continuation ID may be send via POST also. It could be hidden field, and it could be cookie. Usually all web-developers prefer POST with forms just because replies to POST method should not be cached until server explicitly provides expiration header (see HTTP 1.1 specs). All cached pages have a key which is simply URL, for better caching use GET, for non-caching - POST. -- View this message in context: http://www.nabble.com/FW%3A-HTTPD-mod_cache--HttpCacheAction%3A-where-is-304--tf3132401.html#a8695784 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
RE: Not caching pages with continuations (was:...where is 304?)
If it's for CForms, we can add the setting of no-cache headers in Form.js since it's very unlikely that a form pipeline will be cacheable. Think we tried similar things (in flowscript), but we found the problem Bertrand also faced about the fact, that you have to set the headers on the pipeline the serializer is used from (but all requests for example arrive at a catch all matcher, which does not know wether it includes a form or not). Do you think you can set it globally for the request in Form.js? I tried directly manipulating the HttpServletResponse, but obviously, this resulted in correct behavior on the first request, but consecutive cached responses did not have this direct HttpServletResponse manipulation, so this implied uncacheable pipelines in cocoon, which of course, I did not want either. Hmmm, reading this again, of course, CForms aren't cached anyway of course But, I am curious about a possible solution Ard Also, for other flowscripts there could be a parameter on the map:flow instruction stating the flowscript engine has to always set the no-cache headers. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Not caching pages with continuations (was:...where is 304?)
Ard Schrijvers wrote: Hello, Ard Schrijvers wrote: snip/ This is actually almost the same hack we used, but instead of a transformer a selector, and if some value set in flowscript, an action to set headers. Because we are outsourcing/other parties using our best practices, and I did not want them to have to think about setting things in flowscript like sessions and values to indicate caching headers, I chose to put it in the black box transformer, which handles it. Of course, also kind of a hack, because users aren't really aware of it (certainly because i did not want another sax transformer, so I did add it to the StripNameSpaceTransformer which is by default used by us in front of the serializer. But it does more then its name suggests, and therefor, it is hacky ofcourse. But...at least nobody has to think about it :-) ). I wondered if there was a solid nonhacky solution to the issue If it's for CForms, we can add the setting of no-cache headers in Form.js since it's very unlikely that a form pipeline will be cacheable. Think we tried similar things (in flowscript), but we found the problem Bertrand also faced about the fact, that you have to set the headers on the pipeline the serializer is used from (but all requests for example arrive at a catch all matcher, which does not know wether it includes a form or not). Do you think you can set it globally for the request in Form.js? I tried directly manipulating the HttpServletResponse, but obviously, this resulted in correct behavior on the first request, but consecutive cached responses did not have this direct HttpServletResponse manipulation, so this implied uncacheable pipelines in cocoon, which of course, I did not want either. Cached responses don't involve the serializer, and this is why the headers aren't set. On the contrary, the flowscript is always executed, meaning headers will always correctly been set even if the pipeline it calls is cacheable (BTW why is this pipeline cacheable at all???) Also, response.setHeader() is ignored for internal requests. Si if the flowscript is called through a cocoon:, headers really have to be set on the Http request, accessible in the object model with the HttpEnvironment.HTTP_RESPONSE_OBJECT key. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Not caching pages with continuations (was:...where is 304?)
On 1/30/07, Ard Schrijvers [EMAIL PROTECTED] wrote: Do you think you can set it globally for the request in Form.js? I tried directly manipulating the HttpServletResponse, but obviously, this resulted in correct behavior on the first request, but consecutive cached responses did not have this direct HttpServletResponse manipulation, so this implied uncacheable pipelines in cocoon, which of course, I did not want either FWIW, in my apps I'm not using Cocoon caching for the forms building pipelines, which makes the whole thing much easier. But I have light loads on the forms-related parts of those apps. -Bertrand
RE: Not caching pages with continuations (was:...where is 304?)
-- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl -- -Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED] Posted At: dinsdag 30 januari 2007 11:42 Posted To: Cocoon Dev List Conversation: Not caching pages with continuations (was:...where is 304?) Subject: Re: Not caching pages with continuations (was:...where is 304?) Hello, Cached responses don't involve the serializer, and this is why the headers aren't set. On the contrary, the flowscript is always executed, meaning headers will always correctly been set even if the pipeline it calls is cacheable (BTW why is this pipeline cacheable at all???) I indeed already replied on my own remark about caching pipelines involving CForms. Obviously, when using CForms, these are uncacheable Also, response.setHeader() is ignored for internal requests. Si if the flowscript is called through a cocoon:, headers really have to be set on the Http request, accessible in the object model with the HttpEnvironment.HTTP_RESPONSE_OBJECT key. Yes indeed, since the pipeline involving CForms won't be cached anyway, this will work (might be setting a session/cookie to enable sticky sessions whenever CForms are used also be an option, to be able to use them in balanced environments? Perhaps configurable because in not balanced environments it is redundant) I did have problems in a slightly different setting with HttpEnvironment.HTTP_RESPONSE_OBJECT, when you want to set for example a 404 status code in an internal pipeline, but still the entire pipeline can is cacheable. Then, only the first time the response header is set correctly, but not when fetched later from cache. Anyway, for CForms directly manipulating the HttpEnvironment.HTTP_RESPONSE_OBJECT should work fine indeed because they are uncacheable anyway. Ard Sylvain -- Sylvain Wallez - http://bluxte.net
[2.2] can't mount sitemap using resource:// (spring configurator doesn't use SourceResolver?)
Hi, I'm trying to mount a sitemap which is loaded from a resource. The spring configurator seems to have problems with this, because I'm getting a FileNotFoundException. Some parent of ChildXmlWebApplicationContext tries to load the file '/resource://test.xmap' (and I try to load the sitemap 'resource://test.xmap' of course). The code goes trough ChildXmlWebApplicationContext.getResourceByPath(String path), but fails on line 101 (creating a new URL object that starts with the resource:// scheme). Then it captures the error, and delegates the loading to a super class, which tries to load '/resource://test.xmap'. Should the ChildXmlWebApplicationContext use the SourceResolver, instead?? Thanks, Bart.
[continuum] BUILD ERROR: Apache Cocoon
Online report : http://cocoon.zones.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1803 Build statistics: State: Error Previous State: Ok Started at: Tue, 30 Jan 2007 12:01:16 + Finished at: Tue, 30 Jan 2007 12:02:07 + Total time: 51s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Build Error: org.apache.maven.continuum.scm.ContinuumScmException: Error while update sources. at org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:272) at org.apache.maven.continuum.core.action.UpdateWorkingDirectoryFromScmContinuumAction.execute(UpdateWorkingDirectoryFromScmContinuumAction.java:58) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:166) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) at java.lang.Thread.run(Thread.java:534) Caused by: org.apache.maven.scm.ScmException: Exception while executing SCM command. at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59) at org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.executeCommand(AbstractSvnScmProvider.java:336) at org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.update(AbstractSvnScmProvider.java:327) at org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:386) at org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:363) at org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:242) ... 5 more Caused by: org.apache.maven.scm.ScmException: Error while executing command. at org.apache.maven.scm.provider.svn.svnexe.command.update.SvnUpdateCommand.executeUpdateCommand(SvnUpdateCommand.java:67) at org.apache.maven.scm.command.update.AbstractUpdateCommand.executeCommand(AbstractUpdateCommand.java:55) at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:55) ... 10 more Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing process. at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:741) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:79) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:65) at org.apache.maven.scm.provider.svn.svnexe.command.SvnCommandLineUtils.execute(SvnCommandLineUtils.java:88) at org.apache.maven.scm.provider.svn.svnexe.command.update.SvnUpdateCommand.executeUpdateCommand(SvnUpdateCommand.java:63) ... 12 more Caused by: java.io.IOException: Not enough space at java.lang.UNIXProcess.forkAndExec(Native Method) at java.lang.UNIXProcess.init(UNIXProcess.java:52) at java.lang.Runtime.execInternal(Native Method) at java.lang.Runtime.exec(Runtime.java:566) at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:736) ... 16 more
Re: [2.2] can't mount sitemap using resource:// (spring configurator doesn't use SourceResolver?)
Bart Molenkamp wrote: Hi, I'm trying to mount a sitemap which is loaded from a resource. The spring configurator seems to have problems with this, because I'm getting a FileNotFoundException. Some parent of ChildXmlWebApplicationContext tries to load the file '/resource://test.xmap' (and I try to load the sitemap 'resource://test.xmap' of course). The code goes trough ChildXmlWebApplicationContext.getResourceByPath(String path), but fails on line 101 (creating a new URL object that starts with the resource:// scheme). Then it captures the error, and delegates the loading to a super class, which tries to load '/resource://test.xmap'. Should the ChildXmlWebApplicationContext use the SourceResolver, instead?? The configurator should be independent and therefore just use plain spring. Can you add a stack trace please? Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: load flow scripts from directory...?
Mark Lundquist wrote: I think I remember some discussion about map:script being able to scan a directory and load any scripts it finds... can somebody refresh my memory? If you use just map:script in your sitemap, the sitemap loads all scripts from an optional sub directory named flow. The ending of the files depends on the use flow interpreter. In the case of flow script, it's js. HTH Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: [2.2] can't mount sitemap using resource:// (spring configurator doesn't use SourceResolver?)
As said, the sitemap is loaded with map:mount src=resource://test.xmap .../. And the file is available on the classpath. How about using other sources, like the slide:// or xmldb:// to load sitemaps? Are they supported now? java.io.FileNotFoundException: Could not open ServletContext resource [/resource://test.xmap] at org.springframework.web.context.support.ServletContextResource.getInputStream(ServletContextResource.java:99) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.getInputSource(ConfigurationReader.java:170) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.convertSitemap(ConfigurationReader.java:226) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.readSitemap(ConfigurationReader.java:100) at org.apache.cocoon.core.container.spring.avalon.SitemapElementParser.readConfiguration(SitemapElementParser.java:66) at org.apache.cocoon.core.container.spring.avalon.BridgeElementParser.parse(BridgeElementParser.java:74) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:68) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1078) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1068) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:133) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:90) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:495) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:340) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:317) at org.apache.cocoon.spring.configurator.impl.ChildXmlWebApplicationContext.loadBeanDefinitions(ChildXmlWebApplicationContext.java:82) at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:91) at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:94) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:292) at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156) at org.apache.cocoon.core.container.spring.avalon.SitemapHelper.createContainer(SitemapHelper.java:323) at org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage.build(SitemapLanguage.java:344) at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:61) at $Proxy1.build(Unknown Source) at org.apache.cocoon.components.treeprocessor.TreeProcessor.buildConcreteProcessor(TreeProcessor.java:390) at org.apache.cocoon.components.treeprocessor.TreeProcessor.setupConcreteProcessor(TreeProcessor.java:324) at org.apache.cocoon.components.treeprocessor.TreeProcessor.buildPipeline(TreeProcessor.java:245) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:107) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.buildPipeline(ConcreteTreeProcessor.java:187) at
Re: [2.2] can't mount sitemap using resource:// (spring configurator doesn't use SourceResolver?)
Bart Molenkamp wrote: As said, the sitemap is loaded with map:mount src=resource://test.xmap .../. And the file is available on the classpath. How about using other sources, like the slide:// or xmldb:// to load sitemaps? Are they supported now? Hi, no, currently only spring supported protocols work (file, http). Actually this is a bug in the new avalon sitemap support/avalon bridge; this is not a problem of the spring configurator. I agree that we should/use support the source resolver in these cases. Could you please file a bug report? Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
RE: FW: HTTPD mod_cache HttpCacheAction: where is 304?
I don't understand what is a problem. If we need to cache smth, we need clearly GET method without any cookies. Continuation must be a part of URL to be cached. But it does not make a sence, because new request from the same and/or from different user will request URL with different (not-cached yet) unique URL.
RE: Not caching pages with continuations (was:...where is 304?)
Continuation is designed specifically to make User-Form interaction unique, it is IMPOSSIBLE to cache it. URL contains unique continuation Id, we are using GET method, and we are submitting new continuation Id (via hidden field). Response will be unique (not-cached yet), even if we are using httpd and expiration headers.
Re: Not caching pages with continuations
Sylvain Wallez wrote: If it's for CForms, we can add the setting of no-cache headers in Form.js since it's very unlikely that a form pipeline will be cacheable. Not true :) You can easily have cached cforms pages if using stateless cforms with sendForm() and handleForm() js methods. Most popular use cases for stateless forms include search forms, login forms, contact forms which are part of high traffic (and for this reason, cached) pages. Vadim
Re: Not caching pages with continuations
Vadim Gritsenko wrote: Sylvain Wallez wrote: If it's for CForms, we can add the setting of no-cache headers in Form.js since it's very unlikely that a form pipeline will be cacheable. Not true :) You can easily have cached cforms pages if using stateless cforms with sendForm() and handleForm() js methods. Most popular use cases for stateless forms include search forms, login forms, contact forms which are part of high traffic (and for this reason, cached) pages. Good point! So no cache headers should be set in sendFormAndWait(), aka showForm() where a continuation is created, hence preventing caching. Sylvain -- Sylvain Wallez - http://bluxte.net
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 31 January 12:02 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2007-01-31 12:02:16 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: fetch-plugins-descriptors: [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml [get] local file date : Tue Aug 08 23:50:13 GMT+00:00 2006 [get] . [get] last modified = Wed Aug 09 09:07:08 GMT+00:00 2006 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml [get] local file date : Mon Jul 17 11:50:10 GMT+00:00 2006 [get] .. [get] last modified = Mon Jan 08 02:41:05 GMT+00:00 2007 [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.output.pdf -- check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. Trying to update it... init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: [echo] Trying to find the description of org.apache.forrest.plugin.output.pdf in the different descriptor files [echo] Using the descriptor file /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml... [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-local-unversioned-plugin: get-local: [echo] Trying to locally get org.apache.forrest.plugin.output.pdf [echo] Looking in local /export/opt/forrest-trunk/plugins [echo] Found ! init-build-compiler: echo-init: init: compile: jar: local-deploy: [echo] Locally deploying org.apache.forrest.plugin.output.pdf build: [echo] Plugin org.apache.forrest.plugin.output.pdf deployed ! Ready to configure fetch-remote-unversioned-plugin-version-forrest: fetch-remote-unversioned-plugin-unversion-forrest: has-been-downloaded: downloaded-message: uptodate-message: not-found-message: [echo] Fetch-plugin Ok, installing ! unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 file to
Re: Status of javaflow block in 2.2
Hi Bart, I haven't been much active recently, but me and Maurizio worked a lot to have Javaflow working in 2.2 last summer. The 2.2 javaflow block is based on the new common javaflow made by Torsten Curdt (http://jakarta.apache.org/commons/sandbox/javaflow/ ). This uses JCI to load classes and instrument them at runtime, while there is an ant task to instrument them at build time. The problem, back in september, was that Torsten didn't have time to release a new version of JCI, so the patch applied to have javaflow working was commented out waiting for a new release with JCI patches. I still have a rather old version of 2.2 with all patches applied, a patched version of JCI, and javaflow, with real time reloading and re-instrumenting of classes, mostly working on it. Torsten, any news? :D Simone Bart Molenkamp wrote: Hi all, Can someone tell me what the status is of the javaflow block in Cocoon 2.2? I'm trying to use it, but I'm getting an exception (I tried to run the sample): Caused by: org.apache.commons.javaflow.bytecode.EmptyStackException: pop reference at org.apache.commons.javaflow.bytecode.Stack.popReference(Stack.java:163) at org.apache.cocoon.samples.flow.java.CalculatorFlow.getNumber(CalculatorF low.java) at org.apache.cocoon.samples.flow.java.CalculatorFlow.calculator(Calculator Flow.java:27) ... 94 more Does this sample work for others, or is the current implementation simply broken? Thanks, Bart.
Too many emails from Daisy
Although the title of this email might look like spam, it's not spam but it is about spam :) It seems that Daisy is sending changes emails over and over again to the docs mailing list. Does anyone know why and more important how to stop this? Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: [graphics] Artwork for cocoon.apache.org - next steps
Reinhard Poetz wrote:
Thien wrote:
Do you expect us picking one design and you continue from there?
I did a bit of vote counting, #2 and #3 are sharing the same amount of
first choice votes but #3 is ahead overall (with second choice votes).
What I'll do next is to improve #3 a little and we are good to
implement it. Is that ok?
fine by me
Thien,
I'm not sure if anybody has pointed you yet to the new documentation which is in
some ways different to what you can find at http://cocoon.apache.org. Have a
look at http://cocoon.zones.apache.org/dev-docs/. Especially I want to draw your
attention to following things:
- Each deployment unit has its own consistent documentation, e.g.
http://cocoon.zones.apache.org/dev-docs/core-modules/core/2.2/ or
http://cocoon.zones.apache.org/dev-docs/blocks/forms/1.0/489_1_1.html
At the upper right corner you can find the name of the current documentation
unit.
- we have a main menu containing Cocoon Core, Subprojects, Cocoon Blocks
and Maven plugins. This has to appear on each and every page as it is the
only way to jump between documentation units.
- The homepage currently consists of the getting started - getting better -
getting involved table, the news, an overview of the main versions and
a general explanation of what Cocoon actually is. These pieces of
information should find their space in the new homepage design too. IMO
the Getting ... table should be the eye-catcher number 1.
- The left-hand navigation can be up to 4 levels deep.
- Although I would like to have it, it is difficult for us to
maintain a breadcrump navigation like
Apache Cocoon Cocoon Blocks Cocoon Forms [Introduction]
as we can't auto-generate them using existing (meta) data. As long as we
don't have a good idea of how to do it, we should avoid having one.
If you have questions, don't hesistate to ask!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Too many emails from Daisy
Carsten Ziegeler wrote:
Although the title of this email might look like spam, it's not spam but
it is about spam :)
It seems that Daisy is sending changes emails over and over again to the
docs mailing list. Does anyone know why
yes, whenever it is restarted, the mail queue is worked off again. I guess it is
a bug of the particular milestone release that we use as I don't see this
behaviour in my company's Daisy instances which run on Daisy 1.5.1.
and more important how to stop this?
no idea, I would do it if I had an idea. Bruno?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Too many emails from Daisy
Reinhard Poetz wrote: Carsten Ziegeler wrote: Although the title of this email might look like spam, it's not spam but it is about spam :) It seems that Daisy is sending changes emails over and over again to the docs mailing list. Does anyone know why yes, whenever it is restarted, the mail queue is worked off again. I guess it is a bug of the particular milestone release that we use as I don't see this behaviour in my company's Daisy instances which run on Daisy 1.5.1. and more important how to stop this? no idea, I would do it if I had an idea. Bruno? What about updating to 1.5.1 then? I'm a little bit worried by the fact that we are using a milestone and I'm more worried that it seems that Bruno is the only one who is able to help us with Daisy problems. Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: Too many emails from Daisy
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Although the title of this email might look like spam, it's not spam but
it is about spam :)
It seems that Daisy is sending changes emails over and over again to the
docs mailing list. Does anyone know why
yes, whenever it is restarted, the mail queue is worked off again. I guess it is
a bug of the particular milestone release that we use as I don't see this
behaviour in my company's Daisy instances which run on Daisy 1.5.1.
and more important how to stop this?
no idea, I would do it if I had an idea. Bruno?
What about updating to 1.5.1 then? I'm a little bit worried by the fact
that we are using a milestone and I'm more worried that it seems that
Bruno is the only one who is able to help us with Daisy problems.
Since Bruno is the main author of Daisy he's definitly the quickest when it
comes to track down a problem. But this doesn't mean that he is the only one.
Apart fromo the Outerthought guys at least Helma, Ross and I have been using it
in our projects and have a good working knowledge from a user's POV.
Daisy is very well documented and doing an upgrade is usually only following a
list of instructions (after doing a backup), e.g.
http://cocoondev.org/daisydocs-1_5/13/327.html. After looking at this document I
think that this particular upgrade should be very easy as there are no changes
in the data model.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [graphics] Artwork for cocoon.apache.org - next steps
At the upper right corner you can find the name of the current documentation unit. I think you mean upper left corner - we have a main menu containing Cocoon Core, Subprojects, Cocoon Blocks and Maven plugins. This has to appear on each and every page as it is the only way to jump between documentation units. I just sent the template to Helma to show to everyone, looks like I need to change it before that. - The homepage currently consists of the getting started - getting better - getting involved table, the news, an overview of the main versions and a general explanation of what Cocoon actually is. These pieces of information should find their space in the new homepage design too. IMO the Getting ... table should be the eye-catcher number 1. OK, I will do that. I will do some changes and have Helma (thanks!!) to upload the html to show everyone, once the design can be confirmed, how do I go about patching it to the current design? Or should I just send the file to someone who has the right to do just that? Thien
Re: Too many emails from Daisy
Reinhard Poetz wrote: Since Bruno is the main author of Daisy he's definitly the quickest when it comes to track down a problem. But this doesn't mean that he is the only one. Apart fromo the Outerthought guys at least Helma, Ross and I have been using it in our projects and have a good working knowledge from a user's POV. Daisy is very well documented and doing an upgrade is usually only following a list of instructions (after doing a backup), e.g. http://cocoondev.org/daisydocs-1_5/13/327.html. After looking at this document I think that this particular upgrade should be very easy as there are no changes in the data model. Ah great, didn't know all that - this makes me sleep better again :) So, what about updating? Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
