[Dspace-tech] Do I need to remove the Cocoon cache files every time I make a change that affects the XMLUI?
Recently I was changing the browse indices for my Dspace 1.7.2 installation in my dspace.cfg -- for example : webui.browse.index.1 = datecreated:metadata:dc.date.created:date The problem I ran into was that even after restarting Tomcat and my browser - my changes did not show up in the user interface. After a bit of research I ran across an article that recommended removing the Cocoon cache files in Tomcat: rm /usr/local/tomcat/work/Catalina/localhost/_/cache-dir/cocoon-ehcache.data rm /usr/local/tomcat/work/Catalina/localhost/_/cache-dir/cocoon-ehcache.index When I removed these cache files - and restarted Tomcat - the changes that I had expected to see in the UI actually showed up. So - my question - do I need to remove these files in order for changes like this to show up? What about if I just removed the cache files every time I restarted Tomcat - would this be a bad idea? After our Dspace is in production - Tomcat is not restarted all that often. Thanks for any insights... --Dan Galewsky Texas Digital Library/University of Texas -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Do I need to remove the Cocoon cache files every time I make a change that affects the XMLUI?
Hi, Dan, it was good to meet you at OR11. I don't know the official answer to this, but I do know my voodoo answer is, yes, I make it a habit to clear the Cocoon cache if I ever change anything in the XMLUI. I do it often enough that I'd like to develop a button for the XMLUI admin control panel so I can clear the cache, taking advantage of the native Cocoon clearcache method, while Tomcat is up. Though, manually deleting the files works great, and I often need to reboot Tomcat as part of the development process anyway, so I just take a moment, while Tomcat is down, to delete the Cocoon cache files. Perhaps someone with a deeper understanding of Cocoon can respond with something more nuanced than my answer. But I'd say, it can't hurt, if you're developing using XMLUI, to empty the cache files pre-emptively. They are, after all, just cache files, most likely in a development environment. So, no big deal to delete 'em. -- HARDY POTTINGER pottinge...@umsystem.edu University of Missouri Library Systems http://lso.umsystem.edu/~pottingerhj/ No matter how far down the wrong road you've gone, turn back. --Turkish proverb On 6/16/11 1:47 PM, Galewsky, Dan dan.galew...@austin.utexas.edu wrote: Recently I was changing the browse indices for my Dspace 1.7.2 installation in my dspace.cfg -- for example : webui.browse.index.1 = datecreated:metadata:dc.date.created:date The problem I ran into was that even after restarting Tomcat and my browser - my changes did not show up in the user interface. After a bit of research I ran across an article that recommended removing the Cocoon cache files in Tomcat: rm /usr/local/tomcat/work/Catalina/localhost/_/cache-dir/cocoon-ehcache.data rm /usr/local/tomcat/work/Catalina/localhost/_/cache-dir/cocoon-ehcache.index When I removed these cache files - and restarted Tomcat - the changes that I had expected to see in the UI actually showed up. So - my question - do I need to remove these files in order for changes like this to show up? What about if I just removed the cache files every time I restarted Tomcat - would this be a bad idea? After our Dspace is in production - Tomcat is not restarted all that often. Thanks for any insights... --Dan Galewsky Texas Digital Library/University of Texas -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Do I need to remove the Cocoon cache files every time I make a change that affects the XMLUI?
Hi Dan Hardy, There is supposedly a way to trigger Cocoon to 'clear' its cache via the ClearCacheAction built into Cocoon. See: http://comments.gmane.org/gmane.text.xml.cocoon.user/61537 I just tried this out locally in my XMLUI, and it *seems* to work (at least with a few extremely simple tests I've run). But, I'll admit, this is not well tested at all (SO, DON'T TRY THIS IN PRODUCTION, unless you are feeling very gutsy or have verified that it is 100% working for you). In any case, I thought I'd share this patch in case it is helpful (see attached). Currently, it returns an ugly XML response (which is just Cocoon's status information), but we could just as easily work this into the XMLUI Admin Control Panel with a 'prettier' response. This patch applies to [dspace-src]/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/sitemap.xmap (right now its line numbers are based on Trunk, but should work for 1.7.2 or similar) Please let me know if this seems to work for you in your development environments, etc. If it does seem to work well, this seems like something we could easily add to DSpace 1.8's XMLUI Admin Control Panel. - Tim -- Tim Donohue Technical Lead for DSpace Project DuraSpace.org On 6/16/2011 2:30 PM, Pottinger, Hardy J. wrote: Hi, Dan, it was good to meet you at OR11. I don't know the official answer to this, but I do know my voodoo answer is, yes, I make it a habit to clear the Cocoon cache if I ever change anything in the XMLUI. I do it often enough that I'd like to develop a button for the XMLUI admin control panel so I can clear the cache, taking advantage of the native Cocoon clearcache method, while Tomcat is up. Though, manually deleting the files works great, and I often need to reboot Tomcat as part of the development process anyway, so I just take a moment, while Tomcat is down, to delete the Cocoon cache files. Perhaps someone with a deeper understanding of Cocoon can respond with something more nuanced than my answer. But I'd say, it can't hurt, if you're developing using XMLUI, to empty the cache files pre-emptively. They are, after all, just cache files, most likely in a development environment. So, no big deal to delete 'em. -- HARDY POTTINGERpottinge...@umsystem.edu University of Missouri Library Systems http://lso.umsystem.edu/~pottingerhj/ No matter how far down the wrong road you've gone, turn back. --Turkish proverb On 6/16/11 1:47 PM, Galewsky, Dandan.galew...@austin.utexas.edu wrote: Recently I was changing the browse indices for my Dspace 1.7.2 installation in my dspace.cfg -- for example : webui.browse.index.1 = datecreated:metadata:dc.date.created:date The problem I ran into was that even after restarting Tomcat and my browser - my changes did not show up in the user interface. After a bit of research I ran across an article that recommended removing the Cocoon cache files in Tomcat: rm /usr/local/tomcat/work/Catalina/localhost/_/cache-dir/cocoon-ehcache.data rm /usr/local/tomcat/work/Catalina/localhost/_/cache-dir/cocoon-ehcache.index When I removed these cache files - and restarted Tomcat - the changes that I had expected to see in the UI actually showed up. So - my question - do I need to remove these files in order for changes like this to show up? What about if I just removed the cache files every time I restarted Tomcat - would this be a bad idea? After our Dspace is in production - Tomcat is not restarted all that often. Thanks for any insights... --Dan Galewsky Texas Digital Library/University of Texas -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech # This patch file was generated by NetBeans IDE # Following Index: paths are relative to: D:\programming\dspace-trunk\dspace-xmlui\dspace-xmlui-webapp\src\main\webapp # This patch can be applied using context Tools: Patch action on respective folder. # It uses platform neutral UTF-8 encoding and \n newlines. # Above lines and this line are ignored by the patching process. Index: sitemap.xmap --- sitemap.xmap Base (BASE) +++ sitemap.xmap Locally Modified
Re: [Dspace-tech] Do I need to remove the Cocoon cache files every time I make a change that affects the XMLUI?
Neglected to mention in my previous email: Once you apply the previously sent patch, you should be able to clear the Cocoon cache by visiting: http://localhost:8080/xmlui/clearcache Again, it will return a bunch of XML (which is Cocoon Status Info). But, in that XML will be an section like: group name=VM group name=...EHDefaultStore value name=cached line[empty]/line /value value name=size line0 items in cache (0 are empty)/line /value /group /group - Tim On 6/16/2011 4:47 PM, Tim Donohue wrote: Hi Dan Hardy, There is supposedly a way to trigger Cocoon to 'clear' its cache via the ClearCacheAction built into Cocoon. See: http://comments.gmane.org/gmane.text.xml.cocoon.user/61537 I just tried this out locally in my XMLUI, and it *seems* to work (at least with a few extremely simple tests I've run). But, I'll admit, this is not well tested at all (SO, DON'T TRY THIS IN PRODUCTION, unless you are feeling very gutsy or have verified that it is 100% working for you). In any case, I thought I'd share this patch in case it is helpful (see attached). Currently, it returns an ugly XML response (which is just Cocoon's status information), but we could just as easily work this into the XMLUI Admin Control Panel with a 'prettier' response. This patch applies to [dspace-src]/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/sitemap.xmap (right now its line numbers are based on Trunk, but should work for 1.7.2 or similar) Please let me know if this seems to work for you in your development environments, etc. If it does seem to work well, this seems like something we could easily add to DSpace 1.8's XMLUI Admin Control Panel. - Tim -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Do I need to remove the Cocoon cache files every time I make a change that affects the XMLUI?
Hardy Dan, Ok, after a bit more playing around, here's a slightly updated version of the patch that shows it seems to be working (see attached). This updated version adds an additional option: http://localhost:8080/xmlui/statusinfo - will now show the Cocoon Status XML doc (as a base version, to compare /clearcache to) http://localhost:8080/xmlui/clearcache - Clears the Cocoon Cache returns the updated Cocoon Status XML doc So, if you install this patch, you can see it in action. Browse around the XMLUI and visit the /statusinfo path. As you browse around, more and more items will be added to the EHDefaultStore cache (which you can view in the XML returned by /statusinfo). Then, if you visit /clearcache path, that cache will be cleared out. However, I will admit, there's another cache that appears in that Cocoon Status XML, the DefaultTransientStore which is seemingly unaffected by calls to '/clearcache' (it looks to be mostly caching the messages.xml contents). So, I'm not sure this works on *everything*, but most Cocoon cached content should be cleared. Again, all the usual warnings -- DO NOT try this in Production yet. This is just me playing around with the Cocoon Cache to see what may be possible. It still isn't very well tested or guaranteed to be functioning properly. :) - Tim On 6/16/2011 4:52 PM, Tim Donohue wrote: Neglected to mention in my previous email: Once you apply the previously sent patch, you should be able to clear the Cocoon cache by visiting: http://localhost:8080/xmlui/clearcache Again, it will return a bunch of XML (which is Cocoon Status Info). But, in that XML will be an section like: group name=VM group name=...EHDefaultStore value name=cached line[empty]/line /value value name=size line0 items in cache (0 are empty)/line /value /group /group - Tim On 6/16/2011 4:47 PM, Tim Donohue wrote: Hi Dan Hardy, There is supposedly a way to trigger Cocoon to 'clear' its cache via the ClearCacheAction built into Cocoon. See: http://comments.gmane.org/gmane.text.xml.cocoon.user/61537 I just tried this out locally in my XMLUI, and it *seems* to work (at least with a few extremely simple tests I've run). But, I'll admit, this is not well tested at all (SO, DON'T TRY THIS IN PRODUCTION, unless you are feeling very gutsy or have verified that it is 100% working for you). In any case, I thought I'd share this patch in case it is helpful (see attached). Currently, it returns an ugly XML response (which is just Cocoon's status information), but we could just as easily work this into the XMLUI Admin Control Panel with a 'prettier' response. This patch applies to [dspace-src]/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/sitemap.xmap (right now its line numbers are based on Trunk, but should work for 1.7.2 or similar) Please let me know if this seems to work for you in your development environments, etc. If it does seem to work well, this seems like something we could easily add to DSpace 1.8's XMLUI Admin Control Panel. - Tim # This patch file was generated by NetBeans IDE # Following Index: paths are relative to: D:\programming\dspace-trunk\dspace-xmlui\dspace-xmlui-webapp\src\main\webapp # This patch can be applied using context Tools: Patch action on respective folder. # It uses platform neutral UTF-8 encoding and \n newlines. # Above lines and this line are ignored by the patching process. Index: sitemap.xmap --- sitemap.xmap Base (BASE) +++ sitemap.xmap Locally Modified (Based On LOCAL) @@ -192,6 +192,7 @@ map:action name=StartAuthentication src=org.dspace.app.xmlui.aspect.eperson.StartAuthenticationAction/ map:action name=DSpacePropertyFileReader src=org.dspace.app.xmlui.cocoon.DSpacePropertyFileReader / map:action name=PropertyFileReader src=org.dspace.app.xmlui.cocoon.PropertyFileReader / +map:action name=ClearCacheAction logger=sitemap.action.clear-cache src=org.apache.cocoon.acting.ClearCacheAction/ /map:actions map:pipes default=caching map:pipe name=noncaching src=org.apache.cocoon.components.pipeline.impl.NonCachingProcessingPipeline @@ -225,6 +226,20 @@ map:parameter name=expires value=now/ +!-- Clears current Cocoon Cache -- +map:match pattern=clearcache +map:act type=ClearCacheAction +map:generate src=status type=status/ +map:serialize type=xml/ +/map:act + /map:match + +map:match pattern=statusinfo +map:generate src=status type=status/ +map:serialize type=xml/ + /map:match + + !--
