ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 05 April 12:29 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2007-04-05 12:02:15 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: fetch-plugins-descriptors: [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml [get] local file date : Tue Aug 08 23:50:13 GMT+00:00 2006 [get] . [get] last modified = Wed Aug 09 09:07:08 GMT+00:00 2006 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml [get] local file date : Thu Mar 08 01:51:01 GMT+00:00 2007 [get] . [get] last modified = Mon Mar 26 13:07:06 GMT+00:00 2007 [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.output.pdf -- check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. Trying to update it... init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: [echo] Trying to find the description of org.apache.forrest.plugin.output.pdf in the different descriptor files [echo] Using the descriptor file /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml... [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-local-unversioned-plugin: get-local: [echo] Trying to locally get org.apache.forrest.plugin.output.pdf [echo] Looking in local /export/opt/forrest-trunk/plugins [echo] Found ! init-build-compiler: echo-init: init: compile: jar: local-deploy: [echo] Locally deploying org.apache.forrest.plugin.output.pdf build: [echo] Plugin org.apache.forrest.plugin.output.pdf deployed ! Ready to configure fetch-remote-unversioned-plugin-version-forrest: fetch-remote-unversioned-plugin-unversion-forrest: has-been-downloaded: downloaded-message: uptodate-message: not-found-message: [echo] Fetch-plugin Ok, installing ! unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 file to /e
Re: Remove from the output xml
Thanks very much ! Joerg Heinicke wrote: > > On 04.04.2007 19:33, alarcher wrote: > >> I try to find a way to remove the first line of the output xml in cocoon. >> Here's the xml after cocoon serialization : >> >> >> >> Do you know if there's a way to configure serializer for deleting the >> first >> line ? > > Hi Antoine, > > first please try the users list first for such kind of questions. The > dev list is more targeted for the development of Cocoon itself. > > Anyway, to answer your question: The parameter is called > omit-xml-declaration and can be set as parameter on the serializer. The > default sitemap [1] actually has set this parameter already on the wml > serializer: > > mime-type="text/vnd.wap.wml" name="wml" > src="org.apache.cocoon.serialization.XMLSerializer"> > -//WAPFORUM//DTD WML 1.1//EN > > http://www.wapforum.org/DTD/wml_1.1.xml > ASCII > yes > > > Regards > Joerg > > [1] > http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/webapp/sitemap.xmap?revision=477161&view=markup > > -- View this message in context: http://www.nabble.com/Remove-%3C-xml-version%3D%221.0%22-encoding%3D%22ISO-8859-1%22-%3E-from-the-output-xml-tf3527170.html#a9842407 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: Remove from the output xml
On 04.04.2007 19:33, alarcher wrote: I try to find a way to remove the first line of the output xml in cocoon. Here's the xml after cocoon serialization : Do you know if there's a way to configure serializer for deleting the first line ? Hi Antoine, first please try the users list first for such kind of questions. The dev list is more targeted for the development of Cocoon itself. Anyway, to answer your question: The parameter is called omit-xml-declaration and can be set as parameter on the serializer. The default sitemap [1] actually has set this parameter already on the wml serializer: mime-type="text/vnd.wap.wml" name="wml" src="org.apache.cocoon.serialization.XMLSerializer"> -//WAPFORUM//DTD WML 1.1//EN http://www.wapforum.org/DTD/wml_1.1.xml ASCII yes Regards Joerg [1] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/webapp/sitemap.xmap?revision=477161&view=markup
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (102 issues) Subscriber: cocoon Key Summary COCOON-2037 New DynamicGroup widget https://issues.apache.org/jira/browse/COCOON-2037 COCOON-2035 NPE in the sorter of the EnhancedRepeater https://issues.apache.org/jira/browse/COCOON-2035 COCOON-2033 [PATCH] CForms pt_BR messages https://issues.apache.org/jira/browse/COCOON-2033 COCOON-2032 [PATCH] Sort order in paginated repeater https://issues.apache.org/jira/browse/COCOON-2032 COCOON-2030 submit-on-change doesn't work for a multivaluefield with list-type="checkbox" https://issues.apache.org/jira/browse/COCOON-2030 COCOON-2027 [PATCH] Handling of empty responses in AJAX Forms with IFrame transport https://issues.apache.org/jira/browse/COCOON-2027 COCOON-2018 Use thread context class loader to load custom binding classes https://issues.apache.org/jira/browse/COCOON-2018 COCOON-2017 More output beautification options for serializers https://issues.apache.org/jira/browse/COCOON-2017 COCOON-2015 Doctype added twice because root element (html) is inlined https://issues.apache.org/jira/browse/COCOON-2015 COCOON-2002 HTML transformer only works with latin-1 characters https://issues.apache.org/jira/browse/COCOON-2002 COCOON-1993 Make Forms resources loaded directly https://issues.apache.org/jira/browse/COCOON-1993 COCOON-1992 Make Ajax resources loaded directly from cocoon-ajax-impl https://issues.apache.org/jira/browse/COCOON-1992 COCOON-1985 AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline https://issues.apache.org/jira/browse/COCOON-1985 COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the blocks protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for "generator/reader already set" should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1955 [Patch] Allow shielded class loading for a single block https://issues.apache.org/jira/browse/COCOON-1955 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded https://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or XMLizable in JavaSelectionList https://issues.apache.org/jira/browse/COCOON-1915 COCOON-1914 Text as XMLizable in EmptySelectionList https://issues.apache.org/jira/browse/COCOON-1914 COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice https://issues.apache.org/jira/browse/COCOON-1899 COCOON-1898 [PATCH] XPatch support for maven-cocoon-deployer-plugin https://issues.apache.org/jira/browse/COCOON-1898 COCOON-1893 XML-Binding: Problem creating a new element https://issues.apache.org/jira/browse/COCOON-1893 COCOON-1887 Host selector should be case insensitive https://issues.apache.org/jira/browse/COCOON-1887 COCOON-1877 [PATCH] Pageable Repeater https://issues.apache.org/jira/browse/COCOON-1877 COCOON-1870 Lucene block does not store attributes when instructed so https://issues.apache.org/jira/browse/COCOON-1870 COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the rigth time with IE https://issues.apache.org/jira/browse/COCOON-1846 COCOON-1843 LDAPTransformer: add-entry tag doesn't work https://issues.apache.org/jira/browse/COCOON-1843 COCOON-1842 LDAPTransformer: ClassCastException with Binary fields https://issues.apache.org/jira/browse/COCOON-1842 COCOON-1838 Always use 3-digit version number https://issues.apache.org/jira/browse/COCOON-1838 COCOON-1810 [PATCH] JMSEventMessageListener does not work https://issues.apache.org/jira/browse/COCOON-1810 COCOON-1807 Workaround for IE Bug in https://issues.apache.org/jira/browse/COCOON-1807 COCOON-1794 [PATCH] Propagatio
Remove from the output xml
Hi, I try to find a way to remove the first line of the output xml in cocoon. Here's the xml after cocoon serialization : http://www.wapforum.org/DTD/wml_1.1.xml";> Welcome on my wap site Do you know if there's a way to configure serializer for deleting the first line ? Any help will be appreciated. Thanks ! Antoine Larcher -- View this message in context: http://www.nabble.com/Remove-%3C-xml-version%3D%221.0%22-encoding%3D%22ISO-8859-1%22-%3E-from-the-output-xml-tf3527170.html#a9841736 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
cocoon-spring-configurator in trunk not working?
Hi all! I want to use spring-2.0.3, but although all cocoon poms in trunk now reference 2.0.3, the dependency to cocoon-spring-configurator in release version 1.0.0 still pulls in 2.0.2, so effectively that older one is used. Now I changed the dependency to cocoon-spring-configurator to 1.0.1-SNAPSHOT locally, so that I use the version in trunk. But I get the error that the namespace handler for http://cocoon.apache.org/schema/servlet (the servlet services bean stuff) is not registered and Spring throws a NPE while parsing the blockservlet.xml configurations. Where do those namespaces are configured? I could not find any reference. And is spring-configurator in trunk somehow stable or are there new developments in progress? Alex -- Alexander Klimetschek http://www.mindquarry.com
Re: StoreJanitor
On 4/4/07, Ard Schrijvers <[EMAIL PROTECTED]> wrote: > On 4/4/07, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > > Ard Schrijvers wrote: > > > > >> yes please, I would be interested in more comments too! Are > > > > > > more comments like in wiki or in the cocoon.xconf more > comment for different configurations? > > > I can try to write extended documentation on what IMO is > best for configuration, and "tricks" to > > > avoid the StoreJanitor mechanism > > > > I'm interested in further comments by you too, but actually > I meant that other > > people should comment on our plan to change the behaviour > of StoreJanitor. > > Personally, I wonder if you can't just get rid of it altogether? Yes we can, but we have to make sure the default store configurations are such that the maxdiskelements is not set to indefinitely in combination of time2liveseconds and time2idleseconds of 0, or eternal = true. This would mean, cache would always fill all available memory in the end. Proper configured defaults should make the StoreJanitor redundant. +1 to geting rid of the thing completely in that case -- Peter Hunsberger
RE: StoreJanitor
> On 4/4/07, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > > Ard Schrijvers wrote: > > > > >> yes please, I would be interested in more comments too! Are > > > > > > more comments like in wiki or in the cocoon.xconf more > comment for different configurations? > > > I can try to write extended documentation on what IMO is > best for configuration, and "tricks" to > > > avoid the StoreJanitor mechanism > > > > I'm interested in further comments by you too, but actually > I meant that other > > people should comment on our plan to change the behaviour > of StoreJanitor. > > Personally, I wonder if you can't just get rid of it altogether? Yes we can, but we have to make sure the default store configurations are such that the maxdiskelements is not set to indefinitely in combination of time2liveseconds and time2idleseconds of 0, or eternal = true. This would mean, cache would always fill all available memory in the end. Proper configured defaults should make the StoreJanitor redundant. Ard > Do > you think anyone really has dependencies on it and is going to want to > migrate those dependencies to 2.2? > > -- > Peter Hunsberger >
Re: StoreJanitor
On 4/4/07, Reinhard Poetz <[EMAIL PROTECTED]> wrote: Ard Schrijvers wrote: >> yes please, I would be interested in more comments too! Are > > more comments like in wiki or in the cocoon.xconf more comment for different configurations? > I can try to write extended documentation on what IMO is best for configuration, and "tricks" to > avoid the StoreJanitor mechanism I'm interested in further comments by you too, but actually I meant that other people should comment on our plan to change the behaviour of StoreJanitor. Personally, I wonder if you can't just get rid of it altogether? Do you think anyone really has dependencies on it and is going to want to migrate those dependencies to 2.2? -- Peter Hunsberger
Re: StoreJanitor
Ard Schrijvers wrote:
yes please, I would be interested in more comments too! Are
more comments like in wiki or in the cocoon.xconf more comment for different configurations?
I can try to write extended documentation on what IMO is best for configuration, and "tricks" to
avoid the StoreJanitor mechanism
I'm interested in further comments by you too, but actually I meant that other
people should comment on our plan to change the behaviour of StoreJanitor.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Circular deps in servlet connections (was Re: Servlet Services + Shielding)
Grzegorz Kossakowski schrieb: Alexander Klimetschek napisał(a): Yes, this would indeed be better. The super block must not know of its concrete children, but be able to call polymorphic matchers - true OO. Then I can remove the cyclic dep. Alex BTW: When I started to use blocks and especially using the inheritance feature, I was surprised that I manually had to include the forward-**-to-super-block matcher at the end of the child sitemap I'll create issue for this one. Once again: would you like to implement it? If so, just put a message on list. I could easily create the patch for the warning message. Regarding the other solution (automatically resolving the circular dep and thus allowing it): I would now agree to skip this. A bit of research showed that generic circular deps handling is difficult. There are solutions if one specifically knows the two objects (see [1] and [2]). But here we are in a piece of code that has to work generically. Instead, it would be nice to get the real forwarding implemented soon - but I don't know yet where to tackle the servlet-services code to get this done. Alex [1] http://forum.springframework.net/archive/index.php/t-94.html [2] http://forum.springframework.org/archive/index.php/t-10186.html -- Alexander Klimetschek http://www.mindquarry.com
[jira] Commented: (COCOON-2037) New DynamicGroup widget
[ https://issues.apache.org/jira/browse/COCOON-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486663 ] Daniele Madama commented on COCOON-2037: We have a very huge entity, with hundreds of different fields, but we need to show only some of they each time, with this widget we can *split* the different view in each "form snippet" without load the full form on startup (many widget have some logic during the "on-create" phase and so on). Take a look at the patch, it has a sample that can explain the case better of my english ;). > New DynamicGroup widget > --- > > Key: COCOON-2037 > URL: https://issues.apache.org/jira/browse/COCOON-2037 > Project: Cocoon > Issue Type: New Feature > Components: Blocks: Forms >Affects Versions: 2.1.11-dev (Current SVN) >Reporter: Daniele Madama > Fix For: 2.1.11-dev (Current SVN) > > Attachments: dynamicgroup_patch.txt > > > I created a new DynamicGroup widget, with it you can replace all the children > of the group, so you can simply create a *dynamic form* without recreate the > form each time. Usefull for a very huge form that need to show only some > widget at time. > This approach is a little different with the CForms standard because every > time that you replace the children of the dynamic-group you must do a > bindLoad()/bindSave() if you need to preserve the data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2038) Implement true Object Oriented approach for handling super calls
Implement true Object Oriented approach for handling super calls Key: COCOON-2038 URL: https://issues.apache.org/jira/browse/COCOON-2038 Project: Cocoon Issue Type: Task Components: - Servlet service framework Reporter: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Circular deps in servlet connections (was Re: Servlet Services + Shielding)
Alexander Klimetschek napisał(a): > > Yes, this would indeed be better. The super block must not know of its > concrete children, but be able to call polymorphic matchers - true OO. > Then I can remove the cyclic dep. > > Alex > > BTW: When I started to use blocks and especially using the inheritance > feature, I was surprised that I manually had to include the > forward-**-to-super-block matcher at the end of the child sitemap > I'll create issue for this one. Once again: would you like to implement it? If so, just put a message on list. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
[jira] Commented: (COCOON-2037) New DynamicGroup widget
[ https://issues.apache.org/jira/browse/COCOON-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486655 ] Grzegorz Kossakowski commented on COCOON-2037: -- I would like to understand your use case. Why don't you use widget states for this: http://cocoon.zones.apache.org/daisy/cdocs-forms/g1/forms/concepts/733.html > New DynamicGroup widget > --- > > Key: COCOON-2037 > URL: https://issues.apache.org/jira/browse/COCOON-2037 > Project: Cocoon > Issue Type: New Feature > Components: Blocks: Forms >Affects Versions: 2.1.11-dev (Current SVN) >Reporter: Daniele Madama > Fix For: 2.1.11-dev (Current SVN) > > Attachments: dynamicgroup_patch.txt > > > I created a new DynamicGroup widget, with it you can replace all the children > of the group, so you can simply create a *dynamic form* without recreate the > form each time. Usefull for a very huge form that need to show only some > widget at time. > This approach is a little different with the CForms standard because every > time that you replace the children of the dynamic-group you must do a > bindLoad()/bindSave() if you need to preserve the data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2037) New DynamicGroup widget
[ https://issues.apache.org/jira/browse/COCOON-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniele Madama updated COCOON-2037: --- Attachment: dynamicgroup_patch.txt > New DynamicGroup widget > --- > > Key: COCOON-2037 > URL: https://issues.apache.org/jira/browse/COCOON-2037 > Project: Cocoon > Issue Type: New Feature > Components: Blocks: Forms >Affects Versions: 2.1.11-dev (Current SVN) >Reporter: Daniele Madama > Fix For: 2.1.11-dev (Current SVN) > > Attachments: dynamicgroup_patch.txt > > > I created a new DynamicGroup widget, with it you can replace all the children > of the group, so you can simply create a *dynamic form* without recreate the > form each time. Usefull for a very huge form that need to show only some > widget at time. > This approach is a little different with the CForms standard because every > time that you replace the children of the dynamic-group you must do a > bindLoad()/bindSave() if you need to preserve the data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Circular deps in servlet connections (was Re: Servlet Services + Shielding)
Rice Yeh napisał(a): > The idea directly applies to OO's inheritance definition. However, > it might not be easy to implement because it is hard to define "the > looked-up resource does not exist in the extending servlet." Take > flowscript as example, it is usually a javascript error when calling a > method of a non-existent javascript object which exists in the super > servlet but matched in the extending servlet's sitemap. Either you extend block or not you should always be careful about matching patterns. I think it has nothing to do with servlet services if you just create to generic matchers. Now commenting you concern, I do not fully understand "javascript error when calling a method of a non-existent javascript object". Can you explain it a little bit? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
[jira] Created: (COCOON-2037) New DynamicGroup widget
New DynamicGroup widget --- Key: COCOON-2037 URL: https://issues.apache.org/jira/browse/COCOON-2037 Project: Cocoon Issue Type: New Feature Components: Blocks: Forms Affects Versions: 2.1.11-dev (Current SVN) Reporter: Daniele Madama Fix For: 2.1.11-dev (Current SVN) I created a new DynamicGroup widget, with it you can replace all the children of the group, so you can simply create a *dynamic form* without recreate the form each time. Usefull for a very huge form that need to show only some widget at time. This approach is a little different with the CForms standard because every time that you replace the children of the dynamic-group you must do a bindLoad()/bindSave() if you need to preserve the data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: StoreJanitor
>
> I suggest that we don't register them at StoreJanitor by
> default anymore but
> make it configureable for users who rely on it in their custom Store
> implementations/configurations.
+1
>
> AFAIU, StoreJanitor only runs if at least one store is
> registered so we don't
> have to remove it.
>
> >> - fix EventRegistry
> >
>
> I have to learn more about the EventRegistry in order to
> comment on your
> suggestions.
I will mail tonight or tomorrow morning all ins and outs, pros and cons (I know
of at least) of the current
eventRegistry and my suggested (implemented) fix (though we have to discuss
wether I can get it to work for EHCache and wether it needs to be
diskpersistent between JVM restarts)
>
> > 4) you have a memory leak in some custom component (a
> little vague yes :-) )
> > etc
>
> hehe, if we can implement an algorithm that can provide such
> analysis reliably,
> why not ;-)
I think this is extremely hard. Not for the pipeline caches because they store
the response in byte[], but for continuations, internal component maps (for
example i18n resource bundles I think, compiled jx), memory stores which
contain any complex non serializable objects, I think it is impossible to know
the amount of memory. I test these things the most dumb possible way you can
imagine: I crawl my site, and look in status page what happens. I have
many stores in my status page. I have a clear link for each seperate store, and
I look at the memory which gets
freed when clearing one store. This gives me a heuristic measurement of how
large my stores are and should be configured
>
> Are you suggesting some kind of online monitor? I think
> having a seperate
> component would be better than merging it into StoreJanitor.
> This component
> could also be made available as MBean.
See above, very complex I think...and if we fix the standard things that it is
harder for users to
get bugged by the StoreJanitor, and they want to take it to the next level,
there are always things
like yourkit profiler. But, perhaps I am not ambitious enough now :-)
>
>
> yes please, I would be interested in more comments too! Are
more comments like in wiki or in the cocoon.xconf more comment for different
configurations?
I can try to write extended documentation on what IMO is best for
configuration, and "tricks" to
avoid the StoreJanitor mechanism
> Ard and I right that
> we shouldn't register EHDefaultStore and MRUMemoryStore at
> StoreJanitor anymore
> by default and make it configureable instead?
In principle, you could see the StoreJanitor as a real last resort (but IMO, it
will never actually help).
The StoreJanitor might still run, and give proper warnings when low on memory.
Configuring your stores correctly
(and making sure no binary files of many Mb's end up in it), and certainly
having the maxdiskelements
configured should do the trick! Not running the StoreJanitor when JVM is low,
will result in a little faster OOM,
but in my opinion, it differs not much. I also think, the maxdiskelements
should have a sensible default, which
should be less then indefinitely (something like 30.000-50.000 should cover I
think almost everybodies apps)
>
> > Ard
> >
>
> the formatting is okay now, but it seems that your mails
> still don't set the
> in-reply-to header correctly.
Hmmm, I will start using Thunderbird on short notice (not yet today :-) )
>
> --
> Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
>
> {Software Engineering, Open Source, Web Applications, Apache Cocoon}
>
> web(log): http://www.poetz.cc
>
>
Re: Parameters in request get lost when using servlet: protocol
On 4/4/07, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: Sounds good. We had this discussion a few months ago, where Daniel explained the problems with the parameters: http://thread.gmane.org/gmane.text.xml.cocoon.devel/68157 I'd like to mention that there are two things we are talking about (I was mixing them up in my first post ;-): 1) the original HTTP request parameters 2) cocoon attributes that can be set by the caller The first was solved by you easily since it is static and overriding works as expected. But with setting attributes (eg. by an action in a sitemap), the separation between global attributes (for any block) and local attributes (only for the current block and maybe the one's called by him) is needed. There is also the request-scoped bean mentioned, where some work has happened in the last time (regarding cocoon Environment). But I don't know if this is in a state that allows you to do new things or at least implement the 2nd point more easily. Yes, I think a lot of things to meet the requirements in the discussion have been done in trunk but the author (Daniel?) seems not have time to connect all stuffs together. For example, there has been a call frame stack. All I do is just having a quick-but-dirty implementation of the logic I stated earlier. Rice Alex Rice Yeh schrieb: > Not only request.getParameter(String name) has problem but > request.getLocale() has problem too. So I decide to modify some methods in > BlockCallHttpServletRequest. My logic is as follows: > > For parameters: > First ask the request in the current call frame. If a parameter is not > found in the current request, ask the request in the previous call frame. > > For locale: > Directly ask the request in previous call frame and eventually the request > in the first call frame, which is not an instance of > BlockCallHttpServletRequest, answer the question. > > With such logic, a parameter in current request can override the previous > one for the time in current call frame. Once leaving current call frame, > the > overriding effect disappear. > > I test it in my application. It works for me now. But do not know such > logic > applies to others' use cases. > > Rice -- Alexander Klimetschek http://www.mindquarry.com
Re: Circular deps in servlet connections (was Re: Servlet Services + Shielding)
Grzegorz Kossakowski schrieb: In short: I mean that super should work as fallback mechanism. I guess it does not work that way now. However, this would eliminate need for circular dependencies and give cleaner design. What do you think? Yes, this would indeed be better. The super block must not know of its concrete children, but be able to call polymorphic matchers - true OO. Then I can remove the cyclic dep. Alex BTW: When I started to use blocks and especially using the inheritance feature, I was surprised that I manually had to include the forward-**-to-super-block matcher at the end of the child sitemap -- Alexander Klimetschek http://www.mindquarry.com
Re: StoreJanitor
Ard Schrijvers wrote:
- introduce a maxPersistentObjects parameter and use it in
EHDefaultCache to set maxElementsOnDisk
+1
that's easy
- make the registration of stores at StoreJanitor configureable
(Though I wonder what the default value should be, true or false?)
0 : I would avoid the StoreJanitor to run anyway
I suggest that we don't register them at StoreJanitor by default anymore but
make it configureable for users who rely on it in their custom Store
implementations/configurations.
AFAIU, StoreJanitor only runs if at least one store is registered so we don't
have to remove it.
- fix EventRegistry
+1: I have fixed this locally to let it work also when cache entries are
removed by the internals of the cache
I did this, by instead of using the AbstractDoubleMapEventRegistry use
WeakReferences, so that when the cache keys
aren't present anymore, the JVM itself cleans the Registry. Two problems:
1: I removed the persistent cache between JVM retarts, but could rebuild this
(at the cost of long start up times though)
2: With former versions of EHCache, my weakreferences where not honoured when
cache entries where overflowed to disk.
Therefor, I thought EHCache might be doing something with the cachekey when moving to the disk cachekey map. I could only see this behavior in combination with Cocoon, and not when I tested EHCache seperatly.
On the EHCache userlist, Greg told me that it was not possible, and also showed it.
I am using now JCSCache, which I am pretty ok with (only hard configuration)
If by the way, we start fixing the others, like setting a maxdiskobjects, the OOM due to event registry will increase.
This is a problem from MultiHashMap (also the not deprecated replacer) that when you do:
map.put("1","test");
map.put("1","test");
you have two values for key "1".
I have to learn more about the EventRegistry in order to comment on your
suggestions.
Any further ideas?
Hmmm, yes, but I am not sure wether others like it: I think, it might be good,
that
when the StoreJanitor runs, there should be at least an info (error level...? I frequently want to
give info in messages which is so important, that it must be at error level to not be missed, but this
is stupid, right?)
WARN should be good enough IMO.
message about possible problems:
either:
1) your JVM memory settings are too low
ok
2) your stores are configured to have too many memory items
ok
3) your cached objects are very large
ok
4) you have a memory leak in some custom component (a little vague yes :-) )
etc
hehe, if we can implement an algorithm that can provide such analysis reliably,
why not ;-)
Are you suggesting some kind of online monitor? I think having a seperate
component would be better than merging it into StoreJanitor. This component
could also be made available as MBean.
Try runnning a crawler (xenu) and watch your status page memory useage.
Another improvement might be trying to avoid binary readers putting entries in memory cache. But, this might
be to complex for the average user. In principal, I have have been bugging everybody here to:
1) use readers in *noncaching* pipelines, and use appropriate expires times in
the readers, very important
for fast pages because browsers honour the expires time
2) we also read binaries from our repository: these obviously need to be
cached, but what if it are mp3 files
of 15 Mb a piece? Storing this in a normal store...so, I added a protocol,
cached-binary: which in our
setup uses a different store which is configured to have no memory part, only disk cache.
Then again, perhaps the thing above isn't something we can code
definitly
(except for changing some things regarding having multiple event registries),
but...perhaps I should wikify it for the advanced useage? It is though quite some stuff.
Sometimes people have complained to me that
1) cocoon caching is difficult
2) why nobody explained before how cachekeys work, the status generator cachekey overview,
how validities work, etc etc
But, I doubt if there are frameworks around where you get so much ingenious
caching for free,
where 95% of the users never have to know about it. And, indeed, when you want
to run sites
with > 100.000 pages, you indeed need to know more about it. I do think that is normal.
same opinion here
I think it is brilliant of cocoon that we run sites of 100.000 pages with many
users and editors,
which never go down and run everything live with eventcache, and have response
times when cached of within
32 ms (and my latest setups (a skeleton generator with standard conf and sitemaps even go to 0-15 ms)).
I did not get this for free. It took me around 3 months to have everything configured/rebuild/added and understood correctly.
I am not sure about the best way to have it for free for everybody, without needing to understand it all
(or at least get proper info about it).
WDOT?
yes please, I would be i
RE: StoreJanitor
>
> AFAICS there are two freeing algorithms in trunk: round-robin
> and all-stores.
I already thought it would be something like this
> and this is IMO one of the major weakenesses of ehcache (or I
> missed it
> completely), I did not find any way to limit the number of
> disk store entries.
>
> Actually we don't configure this value. According to
> http://ehcache.sourceforge.net/documentation/configuration.htm
> l the default
> value is 0 meaning unlimited. We should use the 1.2.4
> constructor that allows to
> set a maxElementsOnDisk parameter.
That is added lately to ehcache right? I never saw this one, but it is
extremely important to set it to a sensible value in my opinion. Cocoon
uses some quite ingenious caching tricks, but the everage user won't be
aware of the millions of cache entries you can leave behind (like when putting
a timestamp in a cachekey).
>
> I wonder what StoreJanitor is good for at all. EHCache takes
> care that the
> number of items in the memory cache doesn't grow indefinitly
> and starts its own
> cleanup threads for the disc store
> (http://ehcache.sourceforge.net/documentation/storage_options.
> html#DiskStore).
> JCS will probably do the same.
Yes, this is exactly my point. The extra problem is that the StoreJanitor never
has
access to the eviction policy of the cache, and just starts throwing out
entries "at random".
>From my experience, is that my app will only run solid, when the StoreJanitor
>never runs :-)
Therefor, I have created a few store size options to choose from, matching
different
JVM memory sizes. Then, when app is "finished" I start crawling the site (xenu
[1]) for an hour
and look at status generator mem useage or yourkit profiler or something. If I
see the
nice shaped sawtooth (is this only dutch? :-) ) of memory useage, the stores
are configured correctly
> I guess that original purpose
> of StoreJanitor was
> when Cocoon had its own store implementations (transient,
> persistent) and we had
> to take care of cleaning them up in our code.
That must indeed have been the reason (I did not know this one, before my time,
so I have
never understood how the StoreJanitor would ever help me out)
> Only the persistent store can grow unlimited but since it
> should only be used
> for special usecases, it shouldn't be a real problem.
>
>
>
> What do we want to do in order to improve the situation?
> After reading your mail
> and from my own experience I'd say
>
> - introduce a maxPersistentObjects parameter and use it in
> EHDefaultCache to set maxElementsOnDisk
+1
> - make the registration of stores at StoreJanitor configureable
> (Though I wonder what the default value should be, true or false?)
0 : I would avoid the StoreJanitor to run anyway
> - fix EventRegistry
+1: I have fixed this locally to let it work also when cache entries are
removed by the internals of the cache
I did this, by instead of using the AbstractDoubleMapEventRegistry use
WeakReferences, so that when the cache keys
aren't present anymore, the JVM itself cleans the Registry. Two problems:
1: I removed the persistent cache between JVM retarts, but could rebuild this
(at the cost of long start up times though)
2: With former versions of EHCache, my weakreferences where not honoured when
cache entries where overflowed to disk.
Therefor, I thought EHCache might be doing something with the cachekey when
moving to the disk cachekey map. I could only see this behavior in combination
with Cocoon, and not when I tested EHCache seperatly.
On the EHCache userlist, Greg told me that it was not possible, and also showed
it.
I am using now JCSCache, which I am pretty ok with (only hard configuration)
If by the way, we start fixing the others, like setting a maxdiskobjects, the
OOM due to event registry will increase.
This is a problem from MultiHashMap (also the not deprecated replacer) that
when you do:
map.put("1","test");
map.put("1","test");
you have two values for key "1".
>
> Any further ideas?
Hmmm, yes, but I am not sure wether others like it: I think, it might be good,
that
when the StoreJanitor runs, there should be at least an info (error level...? I
frequently want to
give info in messages which is so important, that it must be at error level to
not be missed, but this
is stupid, right?) message about possible problems:
either:
1) your JVM memory settings are too low
2) your stores are configured to have too many memory items
3) your cached objects are very large
4) you have a memory leak in some custom component (a little vague yes :-) )
etc
Try runnning a crawler (xenu) and watch your status page memory useage.
Another improvement might be trying to avoid binary readers putting entries in
memory cache. But, this might
be to complex for the average user. In principal, I have have been bugging
everybody here to:
1) use readers in *noncaching* pipelines, and use appropriate expires times
[jira] Commented: (COCOON-1425) Sessions that use Flowscript are not serializable
[ https://issues.apache.org/jira/browse/COCOON-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486601 ] Reinhard Poetz commented on COCOON-1425: I believe that Javaflow would be the best bet to use continuations together with replicated sessions. Though it still needs some work to get it working. > Sessions that use Flowscript are not serializable > - > > Key: COCOON-1425 > URL: https://issues.apache.org/jira/browse/COCOON-1425 > Project: Cocoon > Issue Type: Bug > Components: - Flowscript >Affects Versions: 2.2-dev (Current SVN) > Environment: Operating System: All > Platform: PC >Reporter: Reinhard Poetz > Assigned To: Cocoon Developers Team > > The scopes of Flowscripts are not serializable. The same is valid for the > continuation objects. This requires a more sophisticated serialization > process. > See http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Parameters in request get lost when using servlet: protocol
Sounds good. We had this discussion a few months ago, where Daniel explained the problems with the parameters: http://thread.gmane.org/gmane.text.xml.cocoon.devel/68157 I'd like to mention that there are two things we are talking about (I was mixing them up in my first post ;-): 1) the original HTTP request parameters 2) cocoon attributes that can be set by the caller The first was solved by you easily since it is static and overriding works as expected. But with setting attributes (eg. by an action in a sitemap), the separation between global attributes (for any block) and local attributes (only for the current block and maybe the one's called by him) is needed. There is also the request-scoped bean mentioned, where some work has happened in the last time (regarding cocoon Environment). But I don't know if this is in a state that allows you to do new things or at least implement the 2nd point more easily. Alex Rice Yeh schrieb: Not only request.getParameter(String name) has problem but request.getLocale() has problem too. So I decide to modify some methods in BlockCallHttpServletRequest. My logic is as follows: For parameters: First ask the request in the current call frame. If a parameter is not found in the current request, ask the request in the previous call frame. For locale: Directly ask the request in previous call frame and eventually the request in the first call frame, which is not an instance of BlockCallHttpServletRequest, answer the question. With such logic, a parameter in current request can override the previous one for the time in current call frame. Once leaving current call frame, the overriding effect disappear. I test it in my application. It works for me now. But do not know such logic applies to others' use cases. Rice -- Alexander Klimetschek http://www.mindquarry.com
[jira] Commented: (COCOON-1425) Sessions that use Flowscript are not serializable
[ https://issues.apache.org/jira/browse/COCOON-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486596 ] Michael Mest commented on COCOON-1425: -- Ok, I see. So there seems to be no possibility to Cluster an Application using Continuations? > Sessions that use Flowscript are not serializable > - > > Key: COCOON-1425 > URL: https://issues.apache.org/jira/browse/COCOON-1425 > Project: Cocoon > Issue Type: Bug > Components: - Flowscript >Affects Versions: 2.2-dev (Current SVN) > Environment: Operating System: All > Platform: PC >Reporter: Reinhard Poetz > Assigned To: Cocoon Developers Team > > The scopes of Flowscripts are not serializable. The same is valid for the > continuation objects. This requires a more sophisticated serialization > process. > See http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: email formatting
> Ard Schrijvers wrote:
> >> Reinhard Poetz wrote:
> >>
> >>> P.S. Ard, answering to your mails is very difficult because
> >> there are no
> >>> line breaks. Is anybody else experiencing the same problem
> >> or is it only
> >>> me?
> >> Jörg pointed me to the "rewrap" function of Thunderbird.
> >> Using it fixes all my
> >> problems with never ending lines. Thanks Jörg!
> >
> > Reading this again, is it an error from my mail settings
>
> Your lines are nearly endless, without any line breaks
>
> > or was it something in Thunderbird?
>
> Thunderbird offers a soltion for this kind of problems. The
> funktion is called
> "rewrap" which adds line breaks at the right places.
>
> > I am always complaining when people send html, so...if my
> mails are wrong as well in format...I should definitely do
> something about it
>
> Thanks!
There will probably be coming a mail in just a moment which won't make you
happy regarding formatting,
but I'll ask around here if somebody knows a solution for me :-)
>
> --
> Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
>
> {Software Engineering, Open Source, Web Applications, Apache Cocoon}
>
> web(log): http://www.poetz.cc
>
>
[jira] Commented: (COCOON-1425) Sessions that use Flowscript are not serializable
[ https://issues.apache.org/jira/browse/COCOON-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486589 ] Reinhard Poetz commented on COCOON-1425: The problem is that the Continuations object has object references that are not serializeable. That's the reason why the WebContinuationsHolder doesn't implement Serializeable. > Sessions that use Flowscript are not serializable > - > > Key: COCOON-1425 > URL: https://issues.apache.org/jira/browse/COCOON-1425 > Project: Cocoon > Issue Type: Bug > Components: - Flowscript >Affects Versions: 2.2-dev (Current SVN) > Environment: Operating System: All > Platform: PC >Reporter: Reinhard Poetz > Assigned To: Cocoon Developers Team > > The scopes of Flowscripts are not serializable. The same is valid for the > continuation objects. This requires a more sophisticated serialization > process. > See http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: email formatting
Ard Schrijvers wrote:
Reinhard Poetz wrote:
P.S. Ard, answering to your mails is very difficult because
there are no
line breaks. Is anybody else experiencing the same problem
or is it only
me?
Jörg pointed me to the "rewrap" function of Thunderbird.
Using it fixes all my
problems with never ending lines. Thanks Jörg!
Reading this again, is it an error from my mail settings
Your lines are nearly endless, without any line breaks
or was it something in Thunderbird?
Thunderbird offers a soltion for this kind of problems. The funktion is called
"rewrap" which adds line breaks at the right places.
I am always complaining when people send html, so...if my mails are wrong as
well in format...I should definitely do something about it
Thanks!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Parameters in request get lost when using servlet: protocol
Not only request.getParameter(String name) has problem but request.getLocale() has problem too. So I decide to modify some methods in BlockCallHttpServletRequest. My logic is as follows: For parameters: First ask the request in the current call frame. If a parameter is not found in the current request, ask the request in the previous call frame. For locale: Directly ask the request in previous call frame and eventually the request in the first call frame, which is not an instance of BlockCallHttpServletRequest, answer the question. With such logic, a parameter in current request can override the previous one for the time in current call frame. Once leaving current call frame, the overriding effect disappear. I test it in my application. It works for me now. But do not know such logic applies to others' use cases. Rice On 4/3/07, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: Rice Yeh schrieb: > Thank you for your solution. But I still feel weird for a brand new request > being created for a called block (servlet), at least for a super block > (servlet). Having a look at the source code, each new brand request and > response are supposed to be stored in its call frame (actually, this > feature > is not implemented yet, but api for retrieving these two objects are > provided). If such design is intended, why not just treat request and > response as part of servlet (block) context. And a way for passing a > request's attributes or parameters must be provided. My real opinion is > that > request should be pass through all servlets invoked, instead of creating a > new one. You are right, as far Cocoon's internal blocks with Sitemap servlets are involved. In that case one can optimize the calls and provide the original context (request, sitemap parameters etc.) to the callee. The only problem you have is how to handle the different parameter levels you have: you might want to have global but sometimes only local parameters, eg. when setting some value in a called block, you don't want it to override a parameter with the same name in the calling block. The advantage of the servlet protocol internally is that you can mount any servlet as a block, not only cocoon's sitemap servlet. We for example have mounted the Solr servlets (for indexing and searching with lucene) as normal blocks. This is a nice feature that allows you to manage your complex web application solely with Cocoon and Spring. Alex -- Alexander Klimetschek http://www.mindquarry.com
[jira] Commented: (COCOON-1425) Sessions that use Flowscript are not serializable
[ https://issues.apache.org/jira/browse/COCOON-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486586 ] Michael Mest commented on COCOON-1425: -- I'm sorry. Seems that it was an error in Testing. Doesn't really work. :-( I get invalid Continuations on Tomcat Cluster. > Sessions that use Flowscript are not serializable > - > > Key: COCOON-1425 > URL: https://issues.apache.org/jira/browse/COCOON-1425 > Project: Cocoon > Issue Type: Bug > Components: - Flowscript >Affects Versions: 2.2-dev (Current SVN) > Environment: Operating System: All > Platform: PC >Reporter: Reinhard Poetz > Assigned To: Cocoon Developers Team > > The scopes of Flowscripts are not serializable. The same is valid for the > continuation objects. This requires a more sophisticated serialization > process. > See http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
email formatting
> > Reinhard Poetz wrote: > > > P.S. Ard, answering to your mails is very difficult because > there are no > > line breaks. Is anybody else experiencing the same problem > or is it only > > me? > > Jörg pointed me to the "rewrap" function of Thunderbird. > Using it fixes all my > problems with never ending lines. Thanks Jörg! Reading this again, is it an error from my mail settings or was it something in Thunderbird? I am always complaining when people send html, so...if my mails are wrong as well in format...I should definitely do something about it Ard
