[jira] Created: (COCOON-2170) Update selection list document page to reflect change to @cache from @dynamic
Update selection list document page to reflect change to @cache from @dynamic -- Key: COCOON-2170 URL: https://issues.apache.org/jira/browse/COCOON-2170 Project: Cocoon Issue Type: Improvement Components: - Documentation Reporter: D Hohls Priority: Trivial In the deprecation log this message: http-8080-Processor10/Deprecation.LoggerWrapper: '@dynamic' mailto:'@dynamic' is deprecated in fd:selection-list and replaced by '@cache' mailto:'@cache' However, on the docs page: http://cocoon.apache.org/2.1/userdocs/widgetconcepts/selectionlists.html There is no mention of the @cache attribute. Can someone please update the page to relfect the discussion shown on: http://svn.apache.org/viewvc?view=revrevision=179906 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problem with flowscript after svn up this morning
Has something changed with Rhino? http://cocoon.zones.apache.org/demos/trunk/samples/forms/form1.flow java.lang.RuntimeException: NOT SUPPORTED at org.mozilla.javascript.Context.compileImpl(Context.java:2353) at org.mozilla.javascript.Context.compileReader(Context.java:1310) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.compileScript(FOM_JavaScriptInterpreter.java:503) at org.apache.cocoon.components.flow.CompilingInterpreter$ScriptSourceEntry.compile(CompilingInterpreter.java:114) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupContext(FOM_JavaScriptInterpreter.java:429) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:575) Joerg On 10.03.2008 08:20, rossputin wrote: I ran an svn up this morning on my Cocoon 2.2, first time in a while, and it seems to have broken flowscript across the board in the cocoon forms samples. I double checked by looking on 'http://cocoon.zones.apache.org/demos/trunk/samples/forms/' and it is the same situation there. The 'Various Actions' sample is fine, but anything involving flowscript is broken. I am not sure if this has already been raised on the list, I did a quick search but could not find anything.
Re: [#COCOON-2168] ResourceReader produces Java Heap Overflow when reading a huge resource - ASF JIRA
Felix Knecht wrote: Joerg Heinicke schrieb: On 05.03.2008 23:06, Joerg Heinicke wrote: From what I see from the code (AbstractProcessingPipeline) it is possible to configure and setup/parameterize a pipeline with outputBufferSize. This means on both map:pipe and map:pipeline it should be possible to set an actual buffer size. Only if none is set (and it defaults to -1) the non-flushing BufferedOutputStream is used. I found a thread on the users list claiming outputBufferSize does not work [1] at the moment (or since some time). Carsten wrote he sees a potential problem but does not outline them. ATM we are always talking about Buffered... I'm believe this has to do with caching the pipelines, right? So I wonder really why my the issue also occurs in noncaching pipelines? Sorry for the late response. I thought that the output stream handling implementation in AbstractEnvironment is wrong. But looking at the code again I'm not sure anymore :( For whatever reason I had the thought the multiple calls to getOutputStream(int) - perhaps with different buffer sizes - could reveal a wrong output stream to be used. Don't know if this is the actual problem, but I think we should throw an exception if getOutputStream is called twice. It should only be called once during a request. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Problem with flowscript after svn up this morning
On Mar 10, 2008, at 8:33 AM, Joerg Heinicke wrote: Has something changed with Rhino? Nope, but was a problem in FOM_JavaScriptInterpreter. fixed. Vadim http://cocoon.zones.apache.org/demos/trunk/samples/forms/form1.flow java.lang.RuntimeException: NOT SUPPORTED at org.mozilla.javascript.Context.compileImpl(Context.java:2353) at org.mozilla.javascript.Context.compileReader(Context.java:1310) at org .apache .cocoon .components .flow .javascript .fom .FOM_JavaScriptInterpreter .compileScript(FOM_JavaScriptInterpreter.java:503) at org.apache.cocoon.components.flow.CompilingInterpreter $ScriptSourceEntry.compile(CompilingInterpreter.java:114) at org .apache .cocoon .components .flow .javascript .fom .FOM_JavaScriptInterpreter .setupContext(FOM_JavaScriptInterpreter.java:429) at org .apache .cocoon .components .flow .javascript .fom .FOM_JavaScriptInterpreter .callFunction(FOM_JavaScriptInterpreter.java:575) Joerg On 10.03.2008 08:20, rossputin wrote: I ran an svn up this morning on my Cocoon 2.2, first time in a while, and it seems to have broken flowscript across the board in the cocoon forms samples. I double checked by looking on 'http://cocoon.zones.apache.org/demos/trunk/samples/forms/' and it is the same situation there. The 'Various Actions' sample is fine, but anything involving flowscript is broken. I am not sure if this has already been raised on the list, I did a quick search but could not find anything.
Problem Posting with CInclude (please help!)
Hi all, I'm trying to post an xml fragment to a REST web service via cinclude, but get the following error. ERROR Mar 9, 2008 1:40:38 PM org.apache.solr.common.SolrException log SEVERE: org.apache.solr.common.SolrException: missing content stream at org.apache.solr.handler.XmlUpdateRequestHandler.handleRequestBody(Xml UpdateRequestHandler.java:114) XSLT cinclude:includexml ignoreErrors=true xmlns:cinclude=http://apache.org/cocoon/include/1.0; cinclude:srchttp://127.0.0.1:8983/solr/update/cinclude:src cinclude:configuration cinclude:parameter cinclude:namemethod/cinclude:name cinclude:valuePOST/cinclude:value /cinclude:parameter /cinclude:configuration cinclude:parameters cinclude:parameter cinclude:nameform-name/cinclude:name cinclude:valueaddsample-fragment-here/add/cinclude:value /cinclude:parameter /cinclude:parameters /cinclude:includexml - - Also, does the CInclude configuration allow setting header parameters? Something like... cinclude:parameter cinclude:nameContent-Type/cinclude:name cinclude:valuetext/xml/cinclude:value /cinclude:parameter cinclude:parameter cinclude:nameCharset/cinclude:name cinclude:valueutf-8/cinclude:value /cinclude:parameter Thanks for your help! Dan -- Dan Hertz's Grape Expectations and Bottle Shots (http://danhertz.com)
