[jira] Created: (COCOON-2245) Not unique caching key for different blocks
Not unique caching key for different blocks --- Key: COCOON-2245 URL: https://issues.apache.org/jira/browse/COCOON-2245 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Felix Knecht ExpiresCachingProcessingPipeline doesn't generates unique default caching key for different blocks. When having 2 blocks running, each containing an image '.../images/foo.png' the key for the cache is 'images/foo.png'. This is wrong as it doesn't respects that this are images of different blocks. The default cache key is generated in core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/components/pipeline/impl/ExpiresCachingProcessingPipeline.java:223: key = environment.getURIPrefix()+environment.getURI(); So the generation of the key is correct, but environment.getURIPrefix() is empty. I'm sure this is the part making the difference. I can't find where the URIPrefix is set (supposing it could be in core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/environment/http/HttpEnvironment.java) ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1822) MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms
[ https://issues.apache.org/jira/browse/COCOON-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617397#action_12617397 ] Felix Knecht commented on COCOON-1822: -- Patch applied to cocoon-forms-impl 1.2.0-SNAPSHOT (cocoon-2.2) MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms Key: COCOON-1822 URL: https://issues.apache.org/jira/browse/COCOON-1822 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9 Reporter: Simone Gianni Assignee: Antonio Gallardo Priority: Critical Attachments: dojo-doublelist_patch.tar.gz The multi value field with fi:styling list-type=double-listbox relies on forms_onsubmitHandlers to select all items in the right selection list before submitting. In an ajax form, it seems like forms_onsubmit is not installed on the form, so handlers are not called; in forms-field-styling.xsl this is clearly stated : xsl:choose xsl:when test=@ajax = 'true' xsl:attribute name=dojoTypeCFormsForm/xsl:attribute xsl:if test=@ajax = 'true' script type=text/javascriptcocoon.forms.ajax = true;/script /xsl:if /xsl:when xsl:otherwise xsl:attribute name=onsubmitforms_onsubmit(); xsl:value-of select=@onsubmit//xsl:attribute /xsl:otherwise /xsl:choose I don't think installing forms_onsubmit() also on ajax forma is a wise solution, but maybe we should call it from inside the ajax code, or at least check and execute onsubmit_handlers. If not, also the free-form multivalue field editor will not work correctly. What's the best way to fix this issue? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1822) MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms
[ https://issues.apache.org/jira/browse/COCOON-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-1822: - Fix Version/s: 2.2-dev (Current SVN) 2.1.12-dev (Current SVN) MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms Key: COCOON-1822 URL: https://issues.apache.org/jira/browse/COCOON-1822 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9 Reporter: Simone Gianni Assignee: Antonio Gallardo Priority: Critical Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: dojo-doublelist_patch.tar.gz The multi value field with fi:styling list-type=double-listbox relies on forms_onsubmitHandlers to select all items in the right selection list before submitting. In an ajax form, it seems like forms_onsubmit is not installed on the form, so handlers are not called; in forms-field-styling.xsl this is clearly stated : xsl:choose xsl:when test=@ajax = 'true' xsl:attribute name=dojoTypeCFormsForm/xsl:attribute xsl:if test=@ajax = 'true' script type=text/javascriptcocoon.forms.ajax = true;/script /xsl:if /xsl:when xsl:otherwise xsl:attribute name=onsubmitforms_onsubmit(); xsl:value-of select=@onsubmit//xsl:attribute /xsl:otherwise /xsl:choose I don't think installing forms_onsubmit() also on ajax forma is a wise solution, but maybe we should call it from inside the ajax code, or at least check and execute onsubmit_handlers. If not, also the free-form multivalue field editor will not work correctly. What's the best way to fix this issue? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2168) ResourceReader produces Java Heap Overflow when reading a huge resource
[ https://issues.apache.org/jira/browse/COCOON-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577373#action_12577373 ] Felix Knecht commented on COCOON-2168: -- After all it turned out that it's a problem of configuration. Thanks to Carsten. Last snippet of the mail thread thread http://marc.info/?t=12047341133r=1w=2 map:pipeline id=test-nocache type=noncaching map:parameter name=outputBufferSize value=0 / map:match pattern=nocache map:read src=/home/felix/tmp/livecd-i686-installer-2007.0.iso map:parameter name=buffer-size value=8192 / /map:read /map:match /map:pipeline The output buffer only specifies the size of the buffer for writing the response. This is not directly related to caching. You might increase performance by buffering. The buffer is in both case unlimited because of allowing proper error handling. If we don't have it yet, we should add these things to a tuning cocoon page. I would turn off infinite buffering in production in all case and set a fixed buffer size (like 8192). For reader pipelines I would turn off buffering completly. ResourceReader produces Java Heap Overflow when reading a huge resource --- Key: COCOON-2168 URL: https://issues.apache.org/jira/browse/COCOON-2168 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Attachments: ResourceReader.diff, test-case.tar.gz When reading a huge resource (i.e. 700MB file) the ResourceReader produces an overflow due to the BufferedOutputStream which is used (and forced to be used via AbstractReader). The BufferedOutputStream flushes only at the end (or when forced to), but overwrites the flush method to do nothing. As I don't know exactly where the BufferedOutputStream is used and what kind of impacts it will have to change it there I'm just going to fix the ResourceReader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2168) ResourceReader produces Java Heap Overflow when reading a huge resource
[ https://issues.apache.org/jira/browse/COCOON-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht closed COCOON-2168. Resolution: Fixed It's a configuration problem. ResourceReader produces Java Heap Overflow when reading a huge resource --- Key: COCOON-2168 URL: https://issues.apache.org/jira/browse/COCOON-2168 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Attachments: ResourceReader.diff, test-case.tar.gz When reading a huge resource (i.e. 700MB file) the ResourceReader produces an overflow due to the BufferedOutputStream which is used (and forced to be used via AbstractReader). The BufferedOutputStream flushes only at the end (or when forced to), but overwrites the flush method to do nothing. As I don't know exactly where the BufferedOutputStream is used and what kind of impacts it will have to change it there I'm just going to fix the ResourceReader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2168) ResourceReader produces Java Heap Overflow when reading a huge resource
[ https://issues.apache.org/jira/browse/COCOON-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575626#action_12575626 ] Felix Knecht commented on COCOON-2168: -- I agree with Joerg that my patch is against the idea of buffering the whole pipeline. OTH (looking at security issues) I think it can be dangerous to accept Overflows by using a default configuration - I don't know how Java behaves in this case. That's why I'd prefer another default value than -1 if none is configured (no matter if it's 8192 or 1024^2). But I think it should be a value which doesn't causes the application to fail when run with default settings and using large resource files. ResourceReader produces Java Heap Overflow when reading a huge resource --- Key: COCOON-2168 URL: https://issues.apache.org/jira/browse/COCOON-2168 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Attachments: ResourceReader.diff, test-case.tar.gz When reading a huge resource (i.e. 700MB file) the ResourceReader produces an overflow due to the BufferedOutputStream which is used (and forced to be used via AbstractReader). The BufferedOutputStream flushes only at the end (or when forced to), but overwrites the flush method to do nothing. As I don't know exactly where the BufferedOutputStream is used and what kind of impacts it will have to change it there I'm just going to fix the ResourceReader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2168) ResourceReader produces Java Heap Overflow when reading a huge resource
ResourceReader produces Java Heap Overflow when reading a huge resource --- Key: COCOON-2168 URL: https://issues.apache.org/jira/browse/COCOON-2168 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assignee: Felix Knecht When reading a huge resource (i.e. 700MB file) the ResourceReader produces an overflow due to the BufferedOutputStream which is used (and forced to be used via AbstractReader). The BufferedOutputStream flushes only at the end (or when forced to), but overwrites the flush method to do nothing. As I don't know exactly where the BufferedOutputStream is used and what kind of impacts it will have to change it there I'm just going to fix the ResourceReader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2168) ResourceReader produces Java Heap Overflow when reading a huge resource
[ https://issues.apache.org/jira/browse/COCOON-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568953#action_12568953 ] Felix Knecht commented on COCOON-2168: -- It seems that the problem is situated somewhere deeper. After fixing the ResourceReader I'm getting next errors, depending on the pipeline I use (caching/noncaching). The errors I'm getting now (after applying the attached patch for the ResourceReader with the test block): Please replace in the test block the file which is read with a huge file you have on your machine (no need to attache a 700MB file here). Caching: 2008-02-14 15:35:20.955:/:INFO: Apache Cocoon Spring Configurator v1.0.2-SNAPSHOT is running in mode 'dev'. java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2786) at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:71) at org.apache.cocoon.servletservice.ServletServiceContext$StatusRetrievableBufferedWrappedResponse$1.write(ServletServiceContext.java:593) at java.io.OutputStream.write(OutputStream.java:99) at org.apache.cocoon.util.BufferedOutputStream.writeBuffer(BufferedOutputStream.java:137) at org.apache.cocoon.util.BufferedOutputStream.realFlush(BufferedOutputStream.java:127) at org.apache.cocoon.reading.ResourceReader.processStream(ResourceReader.java:391) at org.apache.cocoon.reading.ResourceReader.generate(ResourceReader.java:420) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processReader(AbstractProcessingPipeline.java:656) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:431) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72) at $Proxy8.process(Unknown Source) at org.apache.cocoon.components.treeprocessor.sitemap.ReadNode.invoke(ReadNode.java:94) 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:78) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:144) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:81) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:239) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:247) at org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:351) at org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:169) at org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:84) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:512) at org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:479 Noncaching: 2008-02-14 15:34:55.179:/:INFO: Apache Cocoon Spring Configurator v1.0.2-SNAPSHOT is running in mode 'dev'. java.lang.OutOfMemoryError: Java heap space at org.apache.cocoon.util.BufferedOutputStream.incBuffer(BufferedOutputStream.java:148) at org.apache.cocoon.util.BufferedOutputStream.write(BufferedOutputStream.java:96) at org.apache.cocoon.caching.CachingOutputStream.write(CachingOutputStream.java:69) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105) at org.apache.cocoon.reading.ResourceReader.processStream(ResourceReader.java:386) at org.apache.cocoon.reading.ResourceReader.generate(ResourceReader.java:420) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processReader(AbstractCachingProcessingPipeline.java:866) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:431) at
[jira] Updated: (COCOON-2168) ResourceReader produces Java Heap Overflow when reading a huge resource
[ https://issues.apache.org/jira/browse/COCOON-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2168: - Attachment: test-case.tar.gz ResourceReader.diff Patch for ResourceReader Patch with test block ResourceReader produces Java Heap Overflow when reading a huge resource --- Key: COCOON-2168 URL: https://issues.apache.org/jira/browse/COCOON-2168 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assignee: Felix Knecht Attachments: ResourceReader.diff, test-case.tar.gz When reading a huge resource (i.e. 700MB file) the ResourceReader produces an overflow due to the BufferedOutputStream which is used (and forced to be used via AbstractReader). The BufferedOutputStream flushes only at the end (or when forced to), but overwrites the flush method to do nothing. As I don't know exactly where the BufferedOutputStream is used and what kind of impacts it will have to change it there I'm just going to fix the ResourceReader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2168) ResourceReader produces Java Heap Overflow when reading a huge resource
[ https://issues.apache.org/jira/browse/COCOON-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2168: - Assignee: (was: Felix Knecht) Other Info: [Patch available] ResourceReader produces Java Heap Overflow when reading a huge resource --- Key: COCOON-2168 URL: https://issues.apache.org/jira/browse/COCOON-2168 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Attachments: ResourceReader.diff, test-case.tar.gz When reading a huge resource (i.e. 700MB file) the ResourceReader produces an overflow due to the BufferedOutputStream which is used (and forced to be used via AbstractReader). The BufferedOutputStream flushes only at the end (or when forced to), but overwrites the flush method to do nothing. As I don't know exactly where the BufferedOutputStream is used and what kind of impacts it will have to change it there I'm just going to fix the ResourceReader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (COCOON-2150) Error on resetting response
[ https://issues.apache.org/jira/browse/COCOON-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht reopened COCOON-2150: -- Make a clean build and - pointing browser to http://localhost:/ - this looks really ugly - pointing browser to http://localhost:/samples/forms/form1- throws exceptions, looks ugly as well, form tabs are not working Browser: firefox Error on resetting response --- Key: COCOON-2150 URL: https://issues.apache.org/jira/browse/COCOON-2150 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2-dev (Current SVN) Reporter: Jörg Heinicke Assignee: Grzegorz Kossakowski Priority: Minor Fix For: 2.2-dev (Current SVN) This is the exception shown on the console: java.lang.IllegalStateException: Committed at org.mortbay.jetty.Response.resetBuffer(Response.java:855) at org.mortbay.jetty.Response.reset(Response.java:834) at javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:182) at org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:576) at org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:545) at org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy2.service(Unknown Source) at org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:102) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459) It seems to be thrown whenever the response object is reseted after the actual response has been sent by the sitemap error handler. In this case reset is no longer possible since the response has already been committed as stated in the error message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2150) Error on resetting response
[ https://issues.apache.org/jira/browse/COCOON-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2150: - Priority: Critical (was: Minor) Error on resetting response --- Key: COCOON-2150 URL: https://issues.apache.org/jira/browse/COCOON-2150 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2-dev (Current SVN) Reporter: Jörg Heinicke Assignee: Grzegorz Kossakowski Priority: Critical Fix For: 2.2-dev (Current SVN) This is the exception shown on the console: java.lang.IllegalStateException: Committed at org.mortbay.jetty.Response.resetBuffer(Response.java:855) at org.mortbay.jetty.Response.reset(Response.java:834) at javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:182) at org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:576) at org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:545) at org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy2.service(Unknown Source) at org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:102) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459) It seems to be thrown whenever the response object is reseted after the actual response has been sent by the sitemap error handler. In this case reset is no longer possible since the response has already been committed as stated in the error message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2141) Xinha leads to dojo failure for Xinha and HtmlArea
Xinha leads to dojo failure for Xinha and HtmlArea -- Key: COCOON-2141 URL: https://issues.apache.org/jira/browse/COCOON-2141 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Loading XinhaCore.js causes dojo to fail when the form is being submitted. Fehler: too much recursion Quelldatei: http://localhost:/cocoon-ajax-impl/resource/external/dojo/dojo.js Zeile: 96 I'm going to comment the loading and sample of the Xinha stuff until a solution is found. Felix -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2065) huge performance increase of LuceneIndexTransformer on large Lucene indexes
[ https://issues.apache.org/jira/browse/COCOON-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2065: - Fix Version/s: (was: 2.1.11-dev (Current SVN)) Assignee: (was: Felix Knecht) Remove 2.1.11-dev from fixed versions, this tag seemed to be set mistakenly. huge performance increase of LuceneIndexTransformer on large Lucene indexes --- Key: COCOON-2065 URL: https://issues.apache.org/jira/browse/COCOON-2065 Project: Cocoon Issue Type: Improvement Components: Blocks: Lucene Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Dominique De Munck Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: LuceneIndexTransformer.patch PROBLEM: The LuceneIndexTransformer optimizes the Lucene index every time you add an entry to the index. This slows down enormously the indexing with a large index ! If upon every checkin of a document eg, you use it to update the entry, it will slow down. Eg. I have a Pentium IV 2.4 Ghz, Lucene index contains 10 000 doc. Where the index update only takes say 60ms, the optimize that get's called, can take 7 seconds! SOLUTION: I've created a patch that introduces an option optimize-frequency to determine the frequency of the optimize call. It defaults to 1 (current behaviour), when a user sets it to 50, only once every 50 updates the index will be optimized etc If no optimization is wanted, you can set it to 0. This is compliant to the Lucene documentation (fragment of Lucene FAQ): The IndexWriter class supports an optimize() method that compacts the index database and speedup queries. You may want to use this method after performing a complete indexing of your document set or after incremental updates of the index. If your incremental update adds documents frequently, you want to perform the optimization only once in a while to avoid the extra overhead of the optimization. PATCH INFO: added configuration option + a function needToOptimize() which is called before optimizing. needToOptimize() uses a random function generator, to keep code simple. - when the option is not set, CODE WILL BE EXECUTED AS BEFORE - tested one 2.1.11 SVN branch, but no differences in the main trunk thus can be applied there also. - Updated API docs - if patch accepted, I will also update the Wiki: http://wiki.apache.org/cocoon/LuceneIndexTransformer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2091) Add Xinha as an alternative to HTMLArea
[ https://issues.apache.org/jira/browse/COCOON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2091: - Description: The used HTMLArea as webbased editor is no longer actively maintained [1]. Therefore I add an alternative WYSIWYG HTML editor Xinha [2] with a BSD based licence [3]. [1] http://www.dynarch.com/projects/htmlarea/ [2] http://xinha.python-hosting.com/ [3] http://xinha.python-hosting.com/wiki/Licence was: The used HTMLArea as webbased editor is no longer actively maintained [1]. We should switch to Xinha [2]. It's an Opensource WYSIWYG HTML editor with a licence [3] based on BSD license. Can somebody with more knowledge have a look at the license and agree if it's usable for cocoon? [1] http://www.dynarch.com/projects/htmlarea/ [2] http://xinha.python-hosting.com/ [3] http://xinha.python-hosting.com/wiki/Licence Summary: Add Xinha as an alternative to HTMLArea (was: Move from HTMLArea to Xinha) Due to incorrect summary and description I caused some irritations. It's not a replacement, but an additional alternative to HTMLArea (which could replace HTMLArea in future) Add Xinha as an alternative to HTMLArea --- Key: COCOON-2091 URL: https://issues.apache.org/jira/browse/COCOON-2091 Project: Cocoon Issue Type: Task Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assignee: Felix Knecht Fix For: 2.2-dev (Current SVN) The used HTMLArea as webbased editor is no longer actively maintained [1]. Therefore I add an alternative WYSIWYG HTML editor Xinha [2] with a BSD based licence [3]. [1] http://www.dynarch.com/projects/htmlarea/ [2] http://xinha.python-hosting.com/ [3] http://xinha.python-hosting.com/wiki/Licence -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2091) Move from HTMLArea to Xinha
[ https://issues.apache.org/jira/browse/COCOON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht closed COCOON-2091. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) - Added xinha and needed stylesheets to cocoon-forms-impl - Added sample to cocoon-forms-sample The xinha license seems to be still the same license htmlarea used (htmlarea license). As this license has already be used and is also listed in the legal folder I don't see any problems concerning the license. Feel free to reopen if any error occur. Move from HTMLArea to Xinha --- Key: COCOON-2091 URL: https://issues.apache.org/jira/browse/COCOON-2091 Project: Cocoon Issue Type: Task Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assignee: Felix Knecht Fix For: 2.2-dev (Current SVN) The used HTMLArea as webbased editor is no longer actively maintained [1]. We should switch to Xinha [2]. It's an Opensource WYSIWYG HTML editor with a licence [3] based on BSD license. Can somebody with more knowledge have a look at the license and agree if it's usable for cocoon? [1] http://www.dynarch.com/projects/htmlarea/ [2] http://xinha.python-hosting.com/ [3] http://xinha.python-hosting.com/wiki/Licence -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2091) Move from HTMLArea to Xinha
[ https://issues.apache.org/jira/browse/COCOON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht reassigned COCOON-2091: Assignee: Felix Knecht Move from HTMLArea to Xinha --- Key: COCOON-2091 URL: https://issues.apache.org/jira/browse/COCOON-2091 Project: Cocoon Issue Type: Task Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assignee: Felix Knecht The used HTMLArea as webbased editor is no longer actively maintained [1]. We should switch to Xinha [2]. It's an Opensource WYSIWYG HTML editor with a licence [3] based on BSD license. Can somebody with more knowledge have a look at the license and agree if it's usable for cocoon? [1] http://www.dynarch.com/projects/htmlarea/ [2] http://xinha.python-hosting.com/ [3] http://xinha.python-hosting.com/wiki/Licence -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2091) Move from HTMLArea to Xinha
Move from HTMLArea to Xinha --- Key: COCOON-2091 URL: https://issues.apache.org/jira/browse/COCOON-2091 Project: Cocoon Issue Type: Task Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht The used HTMLArea as webbased editor is no longer actively maintained [1]. We should switch to Xinha [2]. It's an Opensource WYSIWYG HTML editor with a licence [3] based on BSD license. Can somebody with more knowledge have a look at the license and agree if it's usable for cocoon? [1] http://www.dynarch.com/projects/htmlarea/ [2] http://xinha.python-hosting.com/ [3] http://xinha.python-hosting.com/wiki/Licence -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2089) ServletService-FW handles missing i18n catalogue files incorrect
[ https://issues.apache.org/jira/browse/COCOON-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht reassigned COCOON-2089: Assignee: Felix Knecht ServletService-FW handles missing i18n catalogue files incorrect Key: COCOON-2089 URL: https://issues.apache.org/jira/browse/COCOON-2089 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assignee: Felix Knecht Attachments: i18n_errorless.patch ServletService throws an exception when a specific language catalogue in a connected block is not found, even when a general catalogue exists. Forcing the error: - Run the cocoon-webapp with the form samples - Choose following link: http://localhost:/blocks/cocoon-forms-sample/form1.flow?locale=de-DE - Click on the Submit Query button You will see the errors in the log file: btpool0-3 ERROR cocoon - Bundle servlet:forms:/resource/internal/i18n/messages_de_DE.xml not loaded: Exception org.apache.cocoon.CascadingIOException: Error during resolving of the input stream at map:read - file:/home/felix/svn/apache/cocoon/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-impl/sitemap.xmap:29:76 OTH when you copy the cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/system/i18n/messages.xml into cocoon-forms-sample/src/main/resources/COB-INF/messages and adapt the cocoon-forms-sample root sitemap to use the local message.xml catalogue file instead of the one from the cocoon-forms-impl block you don't get an error and the general catalogue (messages.xml) is silently used instead of the missing messages_de_DE.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2089) ServletService-FW handles missing i18n catalogue files incorrect
[ https://issues.apache.org/jira/browse/COCOON-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht closed COCOON-2089. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) Reader in sitemap-pipline used to get resource via servlet-services throws CascadingIOException when Resource not found. Adding CascadingIOException to catched exceptions and handle the same way like a SourceNotFoundException. ServletService-FW handles missing i18n catalogue files incorrect Key: COCOON-2089 URL: https://issues.apache.org/jira/browse/COCOON-2089 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assignee: Felix Knecht Fix For: 2.2-dev (Current SVN) Attachments: i18n_errorless.patch ServletService throws an exception when a specific language catalogue in a connected block is not found, even when a general catalogue exists. Forcing the error: - Run the cocoon-webapp with the form samples - Choose following link: http://localhost:/blocks/cocoon-forms-sample/form1.flow?locale=de-DE - Click on the Submit Query button You will see the errors in the log file: btpool0-3 ERROR cocoon - Bundle servlet:forms:/resource/internal/i18n/messages_de_DE.xml not loaded: Exception org.apache.cocoon.CascadingIOException: Error during resolving of the input stream at map:read - file:/home/felix/svn/apache/cocoon/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-impl/sitemap.xmap:29:76 OTH when you copy the cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/system/i18n/messages.xml into cocoon-forms-sample/src/main/resources/COB-INF/messages and adapt the cocoon-forms-sample root sitemap to use the local message.xml catalogue file instead of the one from the cocoon-forms-impl block you don't get an error and the general catalogue (messages.xml) is silently used instead of the missing messages_de_DE.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2089) ServletService-FW handles missing i18n catalogue files incorrect
[ https://issues.apache.org/jira/browse/COCOON-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2089: - Attachment: i18n_errorless.patch Patch how the error can be avoided. ServletService-FW handles missing i18n catalogue files incorrect Key: COCOON-2089 URL: https://issues.apache.org/jira/browse/COCOON-2089 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Attachments: i18n_errorless.patch ServletService throws an exception when a specific language catalogue in a connected block is not found, even when a general catalogue exists. Forcing the error: - Run the cocoon-webapp with the form samples - Choose following link: http://localhost:/blocks/cocoon-forms-sample/form1.flow?locale=de-DE - Click on the Submit Query button You will see the errors in the log file: btpool0-3 ERROR cocoon - Bundle servlet:forms:/resource/internal/i18n/messages_de_DE.xml not loaded: Exception org.apache.cocoon.CascadingIOException: Error during resolving of the input stream at map:read - file:/home/felix/svn/apache/cocoon/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-impl/sitemap.xmap:29:76 OTH when you copy the cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/system/i18n/messages.xml into cocoon-forms-sample/src/main/resources/COB-INF/messages and adapt the cocoon-forms-sample root sitemap to use the local message.xml catalogue file instead of the one from the cocoon-forms-impl block you don't get an error and the general catalogue (messages.xml) is silently used instead of the missing messages_de_DE.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2089) ServletService-FW handles missing i18n catalogue files incorrect
ServletService-FW handles missing i18n catalogue files incorrect Key: COCOON-2089 URL: https://issues.apache.org/jira/browse/COCOON-2089 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht ServletService throws an exception when a specific language catalogue in a connected block is not found, even when a general catalogue exists. Forcing the error: - Run the cocoon-webapp with the form samples - Choose following link: http://localhost:/blocks/cocoon-forms-sample/form1.flow?locale=de-DE - Click on the Submit Query button You will see the errors in the log file: btpool0-3 ERROR cocoon - Bundle servlet:forms:/resource/internal/i18n/messages_de_DE.xml not loaded: Exception org.apache.cocoon.CascadingIOException: Error during resolving of the input stream at map:read - file:/home/felix/svn/apache/cocoon/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-impl/sitemap.xmap:29:76 OTH when you copy the cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/system/i18n/messages.xml into cocoon-forms-sample/src/main/resources/COB-INF/messages and adapt the cocoon-forms-sample root sitemap to use the local message.xml catalogue file instead of the one from the cocoon-forms-impl block you don't get an error and the general catalogue (messages.xml) is silently used instead of the missing messages_de_DE.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2065) huge performance increase of LuceneIndexTransformer on large Lucene indexes
[ https://issues.apache.org/jira/browse/COCOON-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht reassigned COCOON-2065: Assignee: Felix Knecht huge performance increase of LuceneIndexTransformer on large Lucene indexes --- Key: COCOON-2065 URL: https://issues.apache.org/jira/browse/COCOON-2065 Project: Cocoon Issue Type: Improvement Components: Blocks: Lucene Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Dominique De Munck Assignee: Felix Knecht Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: LuceneIndexTransformer.patch PROBLEM: The LuceneIndexTransformer optimizes the Lucene index every time you add an entry to the index. This slows down enormously the indexing with a large index ! If upon every checkin of a document eg, you use it to update the entry, it will slow down. Eg. I have a Pentium IV 2.4 Ghz, Lucene index contains 10 000 doc. Where the index update only takes say 60ms, the optimize that get's called, can take 7 seconds! SOLUTION: I've created a patch that introduces an option optimize-frequency to determine the frequency of the optimize call. It defaults to 1 (current behaviour), when a user sets it to 50, only once every 50 updates the index will be optimized etc If no optimization is wanted, you can set it to 0. This is compliant to the Lucene documentation (fragment of Lucene FAQ): The IndexWriter class supports an optimize() method that compacts the index database and speedup queries. You may want to use this method after performing a complete indexing of your document set or after incremental updates of the index. If your incremental update adds documents frequently, you want to perform the optimization only once in a while to avoid the extra overhead of the optimization. PATCH INFO: added configuration option + a function needToOptimize() which is called before optimizing. needToOptimize() uses a random function generator, to keep code simple. - when the option is not set, CODE WILL BE EXECUTED AS BEFORE - tested one 2.1.11 SVN branch, but no differences in the main trunk thus can be applied there also. - Updated API docs - if patch accepted, I will also update the Wiki: http://wiki.apache.org/cocoon/LuceneIndexTransformer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2065) huge performance increase of LuceneIndexTransformer on large Lucene indexes
[ https://issues.apache.org/jira/browse/COCOON-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht closed COCOON-2065. Resolution: Fixed Due to a lack of knowledge I haven't close the bug after fixing the issues in the last open active branch. huge performance increase of LuceneIndexTransformer on large Lucene indexes --- Key: COCOON-2065 URL: https://issues.apache.org/jira/browse/COCOON-2065 Project: Cocoon Issue Type: Improvement Components: Blocks: Lucene Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Dominique De Munck Assignee: Felix Knecht Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: LuceneIndexTransformer.patch PROBLEM: The LuceneIndexTransformer optimizes the Lucene index every time you add an entry to the index. This slows down enormously the indexing with a large index ! If upon every checkin of a document eg, you use it to update the entry, it will slow down. Eg. I have a Pentium IV 2.4 Ghz, Lucene index contains 10 000 doc. Where the index update only takes say 60ms, the optimize that get's called, can take 7 seconds! SOLUTION: I've created a patch that introduces an option optimize-frequency to determine the frequency of the optimize call. It defaults to 1 (current behaviour), when a user sets it to 50, only once every 50 updates the index will be optimized etc If no optimization is wanted, you can set it to 0. This is compliant to the Lucene documentation (fragment of Lucene FAQ): The IndexWriter class supports an optimize() method that compacts the index database and speedup queries. You may want to use this method after performing a complete indexing of your document set or after incremental updates of the index. If your incremental update adds documents frequently, you want to perform the optimization only once in a while to avoid the extra overhead of the optimization. PATCH INFO: added configuration option + a function needToOptimize() which is called before optimizing. needToOptimize() uses a random function generator, to keep code simple. - when the option is not set, CODE WILL BE EXECUTED AS BEFORE - tested one 2.1.11 SVN branch, but no differences in the main trunk thus can be applied there also. - Updated API docs - if patch accepted, I will also update the Wiki: http://wiki.apache.org/cocoon/LuceneIndexTransformer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2042) Block cocoon-lucene avalon-spring
[ https://issues.apache.org/jira/browse/COCOON-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht closed COCOON-2042. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) Springified the block, added a simple sample for the lucene-index transformer. The samples worked for me and I haven't found any other tests. Block cocoon-lucene avalon-spring -- Key: COCOON-2042 URL: https://issues.apache.org/jira/browse/COCOON-2042 Project: Cocoon Issue Type: Task Components: Blocks: Lucene Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assignee: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Block cocoon-lucene avalon-spring -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2065) huge performance increase of LuceneIndexTransformer on large Lucene indexes
[ https://issues.apache.org/jira/browse/COCOON-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht reassigned COCOON-2065: Assignee: Felix Knecht huge performance increase of LuceneIndexTransformer on large Lucene indexes --- Key: COCOON-2065 URL: https://issues.apache.org/jira/browse/COCOON-2065 Project: Cocoon Issue Type: Improvement Components: Blocks: Lucene Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Dominique De Munck Assignee: Felix Knecht Priority: Minor Fix For: 2.1.11-dev (Current SVN) Attachments: LuceneIndexTransformer.patch PROBLEM: The LuceneIndexTransformer optimizes the Lucene index every time you add an entry to the index. This slows down enormously the indexing with a large index ! If upon every checkin of a document eg, you use it to update the entry, it will slow down. Eg. I have a Pentium IV 2.4 Ghz, Lucene index contains 10 000 doc. Where the index update only takes say 60ms, the optimize that get's called, can take 7 seconds! SOLUTION: I've created a patch that introduces an option optimize-frequency to determine the frequency of the optimize call. It defaults to 1 (current behaviour), when a user sets it to 50, only once every 50 updates the index will be optimized etc If no optimization is wanted, you can set it to 0. This is compliant to the Lucene documentation (fragment of Lucene FAQ): The IndexWriter class supports an optimize() method that compacts the index database and speedup queries. You may want to use this method after performing a complete indexing of your document set or after incremental updates of the index. If your incremental update adds documents frequently, you want to perform the optimization only once in a while to avoid the extra overhead of the optimization. PATCH INFO: added configuration option + a function needToOptimize() which is called before optimizing. needToOptimize() uses a random function generator, to keep code simple. - when the option is not set, CODE WILL BE EXECUTED AS BEFORE - tested one 2.1.11 SVN branch, but no differences in the main trunk thus can be applied there also. - Updated API docs - if patch accepted, I will also update the Wiki: http://wiki.apache.org/cocoon/LuceneIndexTransformer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2065) huge performance increase of LuceneIndexTransformer on large Lucene indexes
[ https://issues.apache.org/jira/browse/COCOON-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2065: - Fix Version/s: 2.2-dev (Current SVN) Patch applied to C2.2_dev huge performance increase of LuceneIndexTransformer on large Lucene indexes --- Key: COCOON-2065 URL: https://issues.apache.org/jira/browse/COCOON-2065 Project: Cocoon Issue Type: Improvement Components: Blocks: Lucene Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Dominique De Munck Assignee: Felix Knecht Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: LuceneIndexTransformer.patch PROBLEM: The LuceneIndexTransformer optimizes the Lucene index every time you add an entry to the index. This slows down enormously the indexing with a large index ! If upon every checkin of a document eg, you use it to update the entry, it will slow down. Eg. I have a Pentium IV 2.4 Ghz, Lucene index contains 10 000 doc. Where the index update only takes say 60ms, the optimize that get's called, can take 7 seconds! SOLUTION: I've created a patch that introduces an option optimize-frequency to determine the frequency of the optimize call. It defaults to 1 (current behaviour), when a user sets it to 50, only once every 50 updates the index will be optimized etc If no optimization is wanted, you can set it to 0. This is compliant to the Lucene documentation (fragment of Lucene FAQ): The IndexWriter class supports an optimize() method that compacts the index database and speedup queries. You may want to use this method after performing a complete indexing of your document set or after incremental updates of the index. If your incremental update adds documents frequently, you want to perform the optimization only once in a while to avoid the extra overhead of the optimization. PATCH INFO: added configuration option + a function needToOptimize() which is called before optimizing. needToOptimize() uses a random function generator, to keep code simple. - when the option is not set, CODE WILL BE EXECUTED AS BEFORE - tested one 2.1.11 SVN branch, but no differences in the main trunk thus can be applied there also. - Updated API docs - if patch accepted, I will also update the Wiki: http://wiki.apache.org/cocoon/LuceneIndexTransformer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2065) huge performance increase of LuceneIndexTransformer on large Lucene indexes
[ https://issues.apache.org/jira/browse/COCOON-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2065: - Assignee: (was: Felix Knecht) huge performance increase of LuceneIndexTransformer on large Lucene indexes --- Key: COCOON-2065 URL: https://issues.apache.org/jira/browse/COCOON-2065 Project: Cocoon Issue Type: Improvement Components: Blocks: Lucene Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Dominique De Munck Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: LuceneIndexTransformer.patch PROBLEM: The LuceneIndexTransformer optimizes the Lucene index every time you add an entry to the index. This slows down enormously the indexing with a large index ! If upon every checkin of a document eg, you use it to update the entry, it will slow down. Eg. I have a Pentium IV 2.4 Ghz, Lucene index contains 10 000 doc. Where the index update only takes say 60ms, the optimize that get's called, can take 7 seconds! SOLUTION: I've created a patch that introduces an option optimize-frequency to determine the frequency of the optimize call. It defaults to 1 (current behaviour), when a user sets it to 50, only once every 50 updates the index will be optimized etc If no optimization is wanted, you can set it to 0. This is compliant to the Lucene documentation (fragment of Lucene FAQ): The IndexWriter class supports an optimize() method that compacts the index database and speedup queries. You may want to use this method after performing a complete indexing of your document set or after incremental updates of the index. If your incremental update adds documents frequently, you want to perform the optimization only once in a while to avoid the extra overhead of the optimization. PATCH INFO: added configuration option + a function needToOptimize() which is called before optimizing. needToOptimize() uses a random function generator, to keep code simple. - when the option is not set, CODE WILL BE EXECUTED AS BEFORE - tested one 2.1.11 SVN branch, but no differences in the main trunk thus can be applied there also. - Updated API docs - if patch accepted, I will also update the Wiki: http://wiki.apache.org/cocoon/LuceneIndexTransformer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2042) Block cocoon-lucene avalon-spring
Block cocoon-lucene avalon-spring -- Key: COCOON-2042 URL: https://issues.apache.org/jira/browse/COCOON-2042 Project: Cocoon Issue Type: Task Components: Blocks: Lucene Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Felix Knecht Priority: Minor Block cocoon-lucene avalon-spring -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2016) captcha sample
[ https://issues.apache.org/jira/browse/COCOON-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484378 ] Felix Knecht commented on COCOON-2016: -- Change applied. Can't close issues - not sufficient karma yet. Felix captcha sample -- Key: COCOON-2016 URL: https://issues.apache.org/jira/browse/COCOON-2016 Project: Cocoon Issue Type: Bug Components: Blocks: Captcha Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: captcha.diff, files2remove.diff Make captcha block working -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2014) Make asciiart sample working
[ https://issues.apache.org/jira/browse/COCOON-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484380 ] Felix Knecht commented on COCOON-2014: -- Change applied. Not sufficient karma yet to close the issue. Felix Make asciiart sample working Key: COCOON-2014 URL: https://issues.apache.org/jira/browse/COCOON-2014 Project: Cocoon Issue Type: Bug Components: Blocks: ASCII Art Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: asciiart_changes.diff, asciiart_deletes.diff Make asciiart sample working. remove avalon configuration I still haven't found out how to delete folders in svn diffs. The asciiart_delete.diff should delete the directory 'blocks/cocoon-asciiart/cocoon-asciiart-impl/src/main/resources/META-INF/cocoon/avalon/'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2014) Make asciiart sample working
[ https://issues.apache.org/jira/browse/COCOON-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht reassigned COCOON-2014: Assignee: Felix Knecht Make asciiart sample working Key: COCOON-2014 URL: https://issues.apache.org/jira/browse/COCOON-2014 Project: Cocoon Issue Type: Bug Components: Blocks: ASCII Art Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: asciiart_changes.diff, asciiart_deletes.diff Make asciiart sample working. remove avalon configuration I still haven't found out how to delete folders in svn diffs. The asciiart_delete.diff should delete the directory 'blocks/cocoon-asciiart/cocoon-asciiart-impl/src/main/resources/META-INF/cocoon/avalon/'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2014) Make asciiart sample working
[ https://issues.apache.org/jira/browse/COCOON-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht closed COCOON-2014. Resolution: Fixed patch applied Make asciiart sample working Key: COCOON-2014 URL: https://issues.apache.org/jira/browse/COCOON-2014 Project: Cocoon Issue Type: Bug Components: Blocks: ASCII Art Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: asciiart_changes.diff, asciiart_deletes.diff Make asciiart sample working. remove avalon configuration I still haven't found out how to delete folders in svn diffs. The asciiart_delete.diff should delete the directory 'blocks/cocoon-asciiart/cocoon-asciiart-impl/src/main/resources/META-INF/cocoon/avalon/'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2016) captcha sample
[ https://issues.apache.org/jira/browse/COCOON-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht reassigned COCOON-2016: Assignee: Felix Knecht captcha sample -- Key: COCOON-2016 URL: https://issues.apache.org/jira/browse/COCOON-2016 Project: Cocoon Issue Type: Bug Components: Blocks: Captcha Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: captcha.diff, files2remove.diff Make captcha block working -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2016) captcha sample
[ https://issues.apache.org/jira/browse/COCOON-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht closed COCOON-2016. Resolution: Fixed patch applied captcha sample -- Key: COCOON-2016 URL: https://issues.apache.org/jira/browse/COCOON-2016 Project: Cocoon Issue Type: Bug Components: Blocks: Captcha Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: captcha.diff, files2remove.diff Make captcha block working -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2019) Make DefaultRunnableManager custom configurable
[ https://issues.apache.org/jira/browse/COCOON-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht reassigned COCOON-2019: Assignee: Felix Knecht Make DefaultRunnableManager custom configurable --- Key: COCOON-2019 URL: https://issues.apache.org/jira/browse/COCOON-2019 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Felix Knecht Fix For: 2.2-dev (Current SVN) Attachments: DefaultRunnableManager.diff Introduce data beans for configuration of the DefaultRunnableManager. This will give the chance to add customized configurations without the need of patch the configuration deployed with the jar file. The new way of configuration uses a bean-map to get the configurations - Every bean implementing the interface ''org.apache.cocoon.components.thread.ThreadPoolConfiguration will be taken as single thread-pool configuration. The two (already existing) configurations default, daemon will still be deployed with the jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2019) Make DefaultRunnableManager custom configurable
[ https://issues.apache.org/jira/browse/COCOON-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht closed COCOON-2019. Resolution: Fixed Refactored ThreadPool. Break out the ThreadPool into a bean. This will make it easier to configure custom thread pools for the RunnableManager. The RunnableManager will load all thread pools implementing the interface 'ThreadPool'. A new thread pool can be added by defining the custom thread pool to add in your spring configuration: !--+ | My thread pool +-- bean name=org.apache.cocoon.components.thread.ThreadPool/myThreadPool class=org.apache.cocoon.components.thread.DefaultThreadPool scope=singleton property name=name value=myThreadPool/ property name=poolPriority value=NORM/ property name=daemon value=true/ property name=queueSize value=0/ property name=maxPoolSize value=-1/ property name=minPoolSize value=1/ property name=keepAliveTime value=6/ property name=blockPolicy value=ABORT/ property name=shutdownGraceful value=false/ property name=shutdownWaitTimeMs value=-1/ property name=factory ref=defaultThreadFactory/ /bean Make DefaultRunnableManager custom configurable --- Key: COCOON-2019 URL: https://issues.apache.org/jira/browse/COCOON-2019 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Felix Knecht Fix For: 2.2-dev (Current SVN) Attachments: DefaultRunnableManager.diff Introduce data beans for configuration of the DefaultRunnableManager. This will give the chance to add customized configurations without the need of patch the configuration deployed with the jar file. The new way of configuration uses a bean-map to get the configurations - Every bean implementing the interface ''org.apache.cocoon.components.thread.ThreadPoolConfiguration will be taken as single thread-pool configuration. The two (already existing) configurations default, daemon will still be deployed with the jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2019) Make DefaultRunnableManager custom configurable
[ https://issues.apache.org/jira/browse/COCOON-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478511 ] Felix Knecht commented on COCOON-2019: -- After some discussions I think also, that Giacomos suggestion is a good way to go. So I will change https://issues.apache.org/jira/browse/COCOON-2019 to go in this direction. snip / Giacomo Pati schrieb: I'd suggest instead of only breaking out the configuration of a thread pool, break out the hole thread pool itself into a bean. This would reduce the complexity of the RunnableManager and would make the ThreadPool beans have a little more responsability than just holding config values. Make DefaultRunnableManager custom configurable --- Key: COCOON-2019 URL: https://issues.apache.org/jira/browse/COCOON-2019 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Fix For: 2.2-dev (Current SVN) Attachments: DefaultRunnableManager.diff Introduce data beans for configuration of the DefaultRunnableManager. This will give the chance to add customized configurations without the need of patch the configuration deployed with the jar file. The new way of configuration uses a bean-map to get the configurations - Every bean implementing the interface ''org.apache.cocoon.components.thread.ThreadPoolConfiguration will be taken as single thread-pool configuration. The two (already existing) configurations default, daemon will still be deployed with the jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2019) Make DefaultRunnableManager custom configurable
Make DefaultRunnableManager custom configurable --- Key: COCOON-2019 URL: https://issues.apache.org/jira/browse/COCOON-2019 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Fix For: 2.2-dev (Current SVN) Attachments: DefaultRunnableManager.diff Introduce data beans for configuration of the DefaultRunnableManager. This will give the chance to add customized configurations without the need of patch the configuration deployed with the jar file. The new way of configuration uses a bean-map to get the configurations - Every bean implementing the interface ''org.apache.cocoon.components.thread.ThreadPoolConfiguration will be taken as single thread-pool configuration. The two (already existing) configurations default, daemon will still be deployed with the jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2019) Make DefaultRunnableManager custom configurable
[ https://issues.apache.org/jira/browse/COCOON-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2019: - Attachment: DefaultRunnableManager.diff The patch Make DefaultRunnableManager custom configurable --- Key: COCOON-2019 URL: https://issues.apache.org/jira/browse/COCOON-2019 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Fix For: 2.2-dev (Current SVN) Attachments: DefaultRunnableManager.diff Introduce data beans for configuration of the DefaultRunnableManager. This will give the chance to add customized configurations without the need of patch the configuration deployed with the jar file. The new way of configuration uses a bean-map to get the configurations - Every bean implementing the interface ''org.apache.cocoon.components.thread.ThreadPoolConfiguration will be taken as single thread-pool configuration. The two (already existing) configurations default, daemon will still be deployed with the jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2016) captcha sample
captcha sample -- Key: COCOON-2016 URL: https://issues.apache.org/jira/browse/COCOON-2016 Project: Cocoon Issue Type: Bug Components: Blocks: Captcha Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Make captcha block working -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2016) captcha sample
[ https://issues.apache.org/jira/browse/COCOON-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2016: - Attachment: files2remove.diff captcha.diff Still having problems to create diffs for files/directories which shall be removed - blocks/cocoon-captcha/cocoon-captcha-sample/src/main/resources/COB-INF/captcha.js (this is moved to ../COB-INF/flow/captcha.js) - blocks/cocoon-captcha/cocoon-captcha-impl/src/main/resources/META-INF/cocoon/avalon captcha sample -- Key: COCOON-2016 URL: https://issues.apache.org/jira/browse/COCOON-2016 Project: Cocoon Issue Type: Bug Components: Blocks: Captcha Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: captcha.diff, files2remove.diff Make captcha block working -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2014) Make asciiart sample working
[ https://issues.apache.org/jira/browse/COCOON-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2014: - Attachment: asciiart_deletes.diff asciiart_changes.diff Make asciiart sample working Key: COCOON-2014 URL: https://issues.apache.org/jira/browse/COCOON-2014 Project: Cocoon Issue Type: Bug Components: Blocks: ASCII Art Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: asciiart_changes.diff, asciiart_deletes.diff Make asciiart sample working. remove avalon configuration I still haven't found out how to delete folders in svn diffs. The asciiart_delete.diff should delete the directory 'blocks/cocoon-asciiart/cocoon-asciiart-impl/src/main/resources/META-INF/cocoon/avalon/'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2014) Make asciiart sample working
Make asciiart sample working Key: COCOON-2014 URL: https://issues.apache.org/jira/browse/COCOON-2014 Project: Cocoon Issue Type: Bug Components: Blocks: ASCII Art Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: asciiart_changes.diff, asciiart_deletes.diff Make asciiart sample working. remove avalon configuration I still haven't found out how to delete folders in svn diffs. The asciiart_delete.diff should delete the directory 'blocks/cocoon-asciiart/cocoon-asciiart-impl/src/main/resources/META-INF/cocoon/avalon/'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1987) Unable to get the object model from the context
[ https://issues.apache.org/jira/browse/COCOON-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474086 ] Felix Knecht commented on COCOON-1987: -- I think so, because the sample is not running without (the configured authentication handlers are not recognized). But it seems that I also trapped into the problem of moving files and then editing them. I'll fixed the patch if there's an interest in. Otherwise the issue can be closed. Unable to get the object model from the context --- Key: COCOON-1987 URL: https://issues.apache.org/jira/browse/COCOON-1987 Project: Cocoon Issue Type: Bug Components: Blocks: Authentication Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Carsten Ziegeler Fix For: 2.2-dev (Current SVN) Attachments: authentication-fw.diff Can't run blocks/cocoon-authentication-fw-sample because of: 2007-01-22 08:34:23.388::WARN: Failed startup of context [EMAIL PROTECTED]/,file:/home/felix/svn/apache/cocoon-2.2.x/core/cocoon-webapp/target/cocoon-webapp/} org.springframework.beans.factory.BeanCreationException: Unable to initialize Avalon component with role org.apache.cocoon.webapps.authentication.AuthenticationManager; nested exception is org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. Caused by: org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. at org.apache.cocoon.components.ContextHelper.getObjectModel(ContextHelper.java:91) at org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.configure(DefaultAuthenticationManager.java:109) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor.postProcessBeforeInitialization(AvalonBeanPostProcessor.java:235) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:302) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1081) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:429) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:273) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:346) at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:451) at org.mortbay.jetty.servlet.Context.startContext(Context.java:124) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1219) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:421) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:496) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119)
[jira] Updated: (COCOON-1987) Unable to get the object model from the context
[ https://issues.apache.org/jira/browse/COCOON-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-1987: - Attachment: deletes.diff additions_and_changes.diff additions_and_changes.diff is selfspeaking. The deletes.diff doesn't works. I want to delete some files, but applying the patch it only generates *.rej files... (don't know why it doesn't works). What I want to delete is the following: blocks/cocoon-authentication-fw/cocoon-authentication-fw-sample/src/main/resources/COB-INF/flow.xmap (file) blocks/cocoon-authentication-fw/cocoon-authentication-fw-sample/src/main/resources/COB-INF/config (directory containing the files auth-manager-flow.xconf and auth-manager.xconf). They are merged into META-INF/cocoon/avalon/auth-manager.xconf (in additi...diff). Hope for more success thand with the previous patch. Unable to get the object model from the context --- Key: COCOON-1987 URL: https://issues.apache.org/jira/browse/COCOON-1987 Project: Cocoon Issue Type: Bug Components: Blocks: Authentication Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Carsten Ziegeler Fix For: 2.2-dev (Current SVN) Attachments: additions_and_changes.diff, authentication-fw.diff, deletes.diff Can't run blocks/cocoon-authentication-fw-sample because of: 2007-01-22 08:34:23.388::WARN: Failed startup of context [EMAIL PROTECTED]/,file:/home/felix/svn/apache/cocoon-2.2.x/core/cocoon-webapp/target/cocoon-webapp/} org.springframework.beans.factory.BeanCreationException: Unable to initialize Avalon component with role org.apache.cocoon.webapps.authentication.AuthenticationManager; nested exception is org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. Caused by: org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. at org.apache.cocoon.components.ContextHelper.getObjectModel(ContextHelper.java:91) at org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.configure(DefaultAuthenticationManager.java:109) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor.postProcessBeforeInitialization(AvalonBeanPostProcessor.java:235) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:302) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1081) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:429) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:273) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:346) at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:451) at org.mortbay.jetty.servlet.Context.startContext(Context.java:124) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1219) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:421) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:496) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156)
[jira] Updated: (COCOON-1987) Unable to get the object model from the context
[ https://issues.apache.org/jira/browse/COCOON-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-1987: - Attachment: authentication-fw.diff The patch you (Carsten) committed works well. Here's the patch I wrote recently about. For me both examples (non- and flowscript are working). From my pov this issue can be closed. Unable to get the object model from the context --- Key: COCOON-1987 URL: https://issues.apache.org/jira/browse/COCOON-1987 Project: Cocoon Issue Type: Bug Components: Blocks: Authentication Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Carsten Ziegeler Fix For: 2.2-dev (Current SVN) Attachments: authentication-fw.diff Can't run blocks/cocoon-authentication-fw-sample because of: 2007-01-22 08:34:23.388::WARN: Failed startup of context [EMAIL PROTECTED]/,file:/home/felix/svn/apache/cocoon-2.2.x/core/cocoon-webapp/target/cocoon-webapp/} org.springframework.beans.factory.BeanCreationException: Unable to initialize Avalon component with role org.apache.cocoon.webapps.authentication.AuthenticationManager; nested exception is org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. Caused by: org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. at org.apache.cocoon.components.ContextHelper.getObjectModel(ContextHelper.java:91) at org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.configure(DefaultAuthenticationManager.java:109) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor.postProcessBeforeInitialization(AvalonBeanPostProcessor.java:235) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:302) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1081) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:429) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:273) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:346) at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:451) at org.mortbay.jetty.servlet.Context.startContext(Context.java:124) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1219) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:421) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:496) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) at org.mortbay.jetty.Server.doStart(Server.java:228) at
[jira] Updated: (COCOON-1987) Unable to get the object model from the context
[ https://issues.apache.org/jira/browse/COCOON-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-1987: - Other Info: [Patch available] Unable to get the object model from the context --- Key: COCOON-1987 URL: https://issues.apache.org/jira/browse/COCOON-1987 Project: Cocoon Issue Type: Bug Components: Blocks: Authentication Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Carsten Ziegeler Fix For: 2.2-dev (Current SVN) Attachments: authentication-fw.diff Can't run blocks/cocoon-authentication-fw-sample because of: 2007-01-22 08:34:23.388::WARN: Failed startup of context [EMAIL PROTECTED]/,file:/home/felix/svn/apache/cocoon-2.2.x/core/cocoon-webapp/target/cocoon-webapp/} org.springframework.beans.factory.BeanCreationException: Unable to initialize Avalon component with role org.apache.cocoon.webapps.authentication.AuthenticationManager; nested exception is org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. Caused by: org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. at org.apache.cocoon.components.ContextHelper.getObjectModel(ContextHelper.java:91) at org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.configure(DefaultAuthenticationManager.java:109) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor.postProcessBeforeInitialization(AvalonBeanPostProcessor.java:235) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:302) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1081) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:429) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:273) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:346) at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:451) at org.mortbay.jetty.servlet.Context.startContext(Context.java:124) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1219) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:421) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:496) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) at org.mortbay.jetty.Server.doStart(Server.java:228) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:134) at
[jira] Commented: (COCOON-1987) Unable to get the object model from the context
[ https://issues.apache.org/jira/browse/COCOON-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473022 ] Felix Knecht commented on COCOON-1987: -- Now I'm getting some other error probably because of the configurations. I'll work on this and provide a patch as soon as I get the sample up and running. BTW: I think I haven't enough Karma to close the issue as I'm not a committer. Unable to get the object model from the context --- Key: COCOON-1987 URL: https://issues.apache.org/jira/browse/COCOON-1987 Project: Cocoon Issue Type: Bug Components: Blocks: Authentication Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Carsten Ziegeler Fix For: 2.2-dev (Current SVN) Can't run blocks/cocoon-authentication-fw-sample because of: 2007-01-22 08:34:23.388::WARN: Failed startup of context [EMAIL PROTECTED]/,file:/home/felix/svn/apache/cocoon-2.2.x/core/cocoon-webapp/target/cocoon-webapp/} org.springframework.beans.factory.BeanCreationException: Unable to initialize Avalon component with role org.apache.cocoon.webapps.authentication.AuthenticationManager; nested exception is org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. Caused by: org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. at org.apache.cocoon.components.ContextHelper.getObjectModel(ContextHelper.java:91) at org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.configure(DefaultAuthenticationManager.java:109) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor.postProcessBeforeInitialization(AvalonBeanPostProcessor.java:235) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:302) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1081) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:429) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:273) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:346) at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:451) at org.mortbay.jetty.servlet.Context.startContext(Context.java:124) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1219) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:421) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:496) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) at org.mortbay.jetty.Server.doStart(Server.java:228) at
[jira] Created: (COCOON-2007) cocoon-block-deployer plugin falis to build war file
cocoon-block-deployer plugin falis to build war file Key: COCOON-2007 URL: https://issues.apache.org/jira/browse/COCOON-2007 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Critical Fix For: 2.2-dev (Current SVN) cocoon-block-deployer plugin can't build war file probably because of version mismatch of dependency in cocoon-block-deployer pom (2.0.1) and root pom pluginManagement (2.0.2). [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war': Unable to find the mojo 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war' in the plugin 'org.apache.maven.plugins:maven-war-plugin' Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-war-plugin:2.0.1:war. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2007) cocoon-block-deployer plugin falis to build war file
[ https://issues.apache.org/jira/browse/COCOON-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2007: - Attachment: deployer-pom.diff patch for cocoon-block-deployer pom.xml cocoon-block-deployer plugin falis to build war file Key: COCOON-2007 URL: https://issues.apache.org/jira/browse/COCOON-2007 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Critical Fix For: 2.2-dev (Current SVN) Attachments: deployer-pom.diff cocoon-block-deployer plugin can't build war file probably because of version mismatch of dependency in cocoon-block-deployer pom (2.0.1) and root pom pluginManagement (2.0.2). [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war': Unable to find the mojo 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war' in the plugin 'org.apache.maven.plugins:maven-war-plugin' Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-war-plugin:2.0.1:war. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2004) cocoon-block-deployer missed renaming of cocoon-block-fw
cocoon-block-deployer missed renaming of cocoon-block-fw Key: COCOON-2004 URL: https://issues.apache.org/jira/browse/COCOON-2004 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Critical cocoon-block-deployer-plugin missed renaming of cocoon-block-fw In the used web.xml is still the old class org.apache.cocoon.blocks.DispatcherServlet used which will result in a CNF exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2004) cocoon-block-deployer missed renaming of cocoon-block-fw
[ https://issues.apache.org/jira/browse/COCOON-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2004: - Attachment: web.xml.diff cocoon-block-deployer missed renaming of cocoon-block-fw Key: COCOON-2004 URL: https://issues.apache.org/jira/browse/COCOON-2004 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Critical Attachments: web.xml.diff cocoon-block-deployer-plugin missed renaming of cocoon-block-fw In the used web.xml is still the old class org.apache.cocoon.blocks.DispatcherServlet used which will result in a CNF exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-1987) Unable to get the object model from the context
Unable to get the object model from the context --- Key: COCOON-1987 URL: https://issues.apache.org/jira/browse/COCOON-1987 Project: Cocoon Issue Type: Bug Components: Blocks: Authentication Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Fix For: 2.2-dev (Current SVN) Can't run blocks/cocoon-authentication-fw-sample because of: 2007-01-22 08:34:23.388::WARN: Failed startup of context [EMAIL PROTECTED]/,file:/home/felix/svn/apache/cocoon-2.2.x/core/cocoon-webapp/target/cocoon-webapp/} org.springframework.beans.factory.BeanCreationException: Unable to initialize Avalon component with role org.apache.cocoon.webapps.authentication.AuthenticationManager; nested exception is org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. Caused by: org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. at org.apache.cocoon.components.ContextHelper.getObjectModel(ContextHelper.java:91) at org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.configure(DefaultAuthenticationManager.java:109) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor.postProcessBeforeInitialization(AvalonBeanPostProcessor.java:235) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:302) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1081) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:429) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:273) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:346) at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:451) at org.mortbay.jetty.servlet.Context.startContext(Context.java:124) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1219) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:421) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:496) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) at org.mortbay.jetty.Server.doStart(Server.java:228) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:134) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:332) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:277) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:195) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:183) at
[jira] Updated: (COCOON-1988) Make cocoon-auth-samples working
[ https://issues.apache.org/jira/browse/COCOON-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-1988: - Attachment: cocoon-webapp.diff cocoon-auth.sample.diff Make cocoon-auth-samples working Key: COCOON-1988 URL: https://issues.apache.org/jira/browse/COCOON-1988 Project: Cocoon Issue Type: Bug Components: - Samples Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: cocoon-auth.sample.diff, cocoon-webapp.diff Make the cocoon-auth sample working and add it to the allblocks profile of cocoon-webapp. Regards Felix -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1988) Make cocoon-auth-samples working
Make cocoon-auth-samples working Key: COCOON-1988 URL: https://issues.apache.org/jira/browse/COCOON-1988 Project: Cocoon Issue Type: Bug Components: - Samples Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: cocoon-auth.sample.diff, cocoon-webapp.diff Make the cocoon-auth sample working and add it to the allblocks profile of cocoon-webapp. Regards Felix -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1988) Make cocoon-auth-samples working
[ https://issues.apache.org/jira/browse/COCOON-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-1988: - Attachment: cocoon-webapp1.diff The former cocoon-webapp.diff patch puts the cocoon-auth-samples into default instead of into the allblocks profile. Not having enough karma to remove the existing patch cocoon-webapp.diff Make cocoon-auth-samples working Key: COCOON-1988 URL: https://issues.apache.org/jira/browse/COCOON-1988 Project: Cocoon Issue Type: Bug Components: - Samples Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: cocoon-auth.sample.diff, cocoon-webapp.diff, cocoon-webapp1.diff Make the cocoon-auth sample working and add it to the allblocks profile of cocoon-webapp. Regards Felix -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-1986) Can't run block cocoon-session-fw-impl
Can't run block cocoon-session-fw-impl -- Key: COCOON-1986 URL: https://issues.apache.org/jira/browse/COCOON-1986 Project: Cocoon Issue Type: Bug Components: Blocks: Session Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Critical Fix For: 2.2-dev (Current SVN) Caused by: java.io.FileNotFoundException: class path resource [org/apache/cocoon/webapps/session/session.roles] cannot be resolved to URL because it does not exist at org.springframework.core.io.ClassPathResource.getURL(ClassPathResource.java:155) at org.apache.cocoon.spring.configurator.ResourceUtils.getUri(ResourceUtils.java:55) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.loadURI(ConfigurationReader.java:497) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.handleInclude(ConfigurationReader.java:458) ... 65 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1986) Can't run block cocoon-session-fw-impl
[ https://issues.apache.org/jira/browse/COCOON-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-1986: - Attachment: patch.txt Can't run block cocoon-session-fw-impl -- Key: COCOON-1986 URL: https://issues.apache.org/jira/browse/COCOON-1986 Project: Cocoon Issue Type: Bug Components: Blocks: Session Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Carsten Ziegeler Priority: Critical Fix For: 2.2-dev (Current SVN) Attachments: patch.txt Caused by: java.io.FileNotFoundException: class path resource [org/apache/cocoon/webapps/session/session.roles] cannot be resolved to URL because it does not exist at org.springframework.core.io.ClassPathResource.getURL(ClassPathResource.java:155) at org.apache.cocoon.spring.configurator.ResourceUtils.getUri(ResourceUtils.java:55) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.loadURI(ConfigurationReader.java:497) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.handleInclude(ConfigurationReader.java:458) ... 65 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (COCOON-1986) Can't run block cocoon-session-fw-impl
[ https://issues.apache.org/jira/browse/COCOON-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht reopened COCOON-1986: -- org.apache.cocoon.components.ExtendedComponentSelector doesn't exists anymore in cocoon-2.2. Is probably org.apache.cocoon.core.container.DefaultServiceSelector. Sorry Carsten, I was too quick. Can't run block cocoon-session-fw-impl -- Key: COCOON-1986 URL: https://issues.apache.org/jira/browse/COCOON-1986 Project: Cocoon Issue Type: Bug Components: Blocks: Session Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Carsten Ziegeler Priority: Critical Fix For: 2.2-dev (Current SVN) Attachments: patch.txt Caused by: java.io.FileNotFoundException: class path resource [org/apache/cocoon/webapps/session/session.roles] cannot be resolved to URL because it does not exist at org.springframework.core.io.ClassPathResource.getURL(ClassPathResource.java:155) at org.apache.cocoon.spring.configurator.ResourceUtils.getUri(ResourceUtils.java:55) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.loadURI(ConfigurationReader.java:497) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.handleInclude(ConfigurationReader.java:458) ... 65 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1986) Can't run block cocoon-session-fw-impl
[ https://issues.apache.org/jira/browse/COCOON-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-1986: - Other Info: [Patch available] Can't run block cocoon-session-fw-impl -- Key: COCOON-1986 URL: https://issues.apache.org/jira/browse/COCOON-1986 Project: Cocoon Issue Type: Bug Components: Blocks: Session Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Carsten Ziegeler Priority: Critical Fix For: 2.2-dev (Current SVN) Attachments: patch.txt Caused by: java.io.FileNotFoundException: class path resource [org/apache/cocoon/webapps/session/session.roles] cannot be resolved to URL because it does not exist at org.springframework.core.io.ClassPathResource.getURL(ClassPathResource.java:155) at org.apache.cocoon.spring.configurator.ResourceUtils.getUri(ResourceUtils.java:55) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.loadURI(ConfigurationReader.java:497) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.handleInclude(ConfigurationReader.java:458) ... 65 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1982) MIssing backslash in log4j.xml
[
https://issues.apache.org/jira/browse/COCOON-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Knecht updated COCOON-1982:
-
Attachment: patch.txt
MIssing backslash in log4j.xml
--
Key: COCOON-1982
URL: https://issues.apache.org/jira/browse/COCOON-1982
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Felix Knecht
Priority: Trivial
Fix For: 2.2-dev (Current SVN)
Attachments: patch.txt
Can't parse chunk: {org.apache.cocoon.work.directory}/cocoon-logs/log4j.log
/
param name=Append value=false /
layout class=org.apache.log4j.PatternLayout
param name=ConversionPattern value=%t %-5p %c{2} - %m%n/
/layout
/appender
line 1:35: unexpected char: '/'
at
org.antlr.stringtemplate.language.ActionLexer.nextToken(ActionLexer.java:217)
at antlr.TokenBuffer.fill(TokenBuffer.java:69)
at antlr.TokenBuffer.LA(TokenBuffer.java:80)
at antlr.LLkParser.LA(LLkParser.java:52)
at
org.antlr.stringtemplate.language.ActionParser.templatesExpr(ActionParser.java:182)
at
org.antlr.stringtemplate.language.ActionParser.action(ActionParser.java:117)
at
org.antlr.stringtemplate.StringTemplate.parseAction(StringTemplate.java:845)
at
org.antlr.stringtemplate.language.TemplateParser.action(TemplateParser.java:151)
at
org.antlr.stringtemplate.language.TemplateParser.template(TemplateParser.java:119)
at
org.antlr.stringtemplate.StringTemplate.breakTemplateIntoChunks(StringTemplate.java:821)
at
org.antlr.stringtemplate.StringTemplate.setTemplate(StringTemplate.java:428)
at
org.antlr.stringtemplate.StringTemplate.init(StringTemplate.java:333)
at
org.antlr.stringtemplate.StringTemplate.init(StringTemplate.java:318)
at
org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.writeStringTemplateToFile(MonolithicCocoonDeployer.java:237)
at
org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:114)
at
org.apache.cocoon.maven.deployer.AbstractDeployMojo.blockDeploymentMonolithicCocoon(AbstractDeployMojo.java:255)
at
org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute(DeployExplodedMojo.java:66)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1983) MIssed renaming of log4j.xconf to log4j.xml
MIssed renaming of log4j.xconf to log4j.xml --- Key: COCOON-1983 URL: https://issues.apache.org/jira/browse/COCOON-1983 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) MIssed renaming of log4j.xconf to log4j.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1983) MIssed renaming of log4j.xconf to log4j.xml
[ https://issues.apache.org/jira/browse/COCOON-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-1983: - Attachment: patch.txt MIssed renaming of log4j.xconf to log4j.xml --- Key: COCOON-1983 URL: https://issues.apache.org/jira/browse/COCOON-1983 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: patch.txt MIssed renaming of log4j.xconf to log4j.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1983) MIssed renaming of log4j.xconf to log4j.xml
[ https://issues.apache.org/jira/browse/COCOON-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-1983: - Priority: Major (was: Minor) Blockdeploy not possible [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at java.io.Reader.init(Reader.java:61) at java.io.InputStreamReader.init(InputStreamReader.java:55) at org.apache.commons.io.IOUtils.copy(IOUtils.java:1020) at org.apache.commons.io.IOUtils.toString(IOUtils.java:358) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.writeStringTemplateToFile(MonolithicCocoonDeployer.java:237) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:114) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.blockDeploymentMonolithicCocoon(AbstractDeployMojo.java:255) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute(DeployExplodedMojo.java:66) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) MIssed renaming of log4j.xconf to log4j.xml --- Key: COCOON-1983 URL: https://issues.apache.org/jira/browse/COCOON-1983 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Fix For: 2.2-dev (Current SVN) Attachments: patch.txt MIssed renaming of log4j.xconf to log4j.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
