Maintenance

We've now written XSLT to patch the four config files for Cocoon and exist automatically, and that seems to be working, as well as using patch to patch the build.properties file. The whole automated system is running very well, but the results currently don't have a working JNLP -- don't know why, but perhaps something in the trunk has changed which has broken it. I'll try a fresh build with a completely new checkout tomorrow. This is really tiring, but we'll eventually get there...

I finally figured this out. This is the sequence to make a working Cocoon webapp:

1. Checkout eXist from SVN.
2. Copy our local.build.properties file into the Cocoon tree (this turns off the Lucene and querybean in Cocoon, per instructions from WM.
3. Copy our own build.properties file into the eXist tree (this contains the path to the Cocoon tree on our system).
4. Sign the eXist jars (required for the JNLP client to work):
   ./build.sh -f build/scripts/jarsigner.xml
5. Do a complete build of eXist (required to generate a conf.xml):
   ./build.sh all
6. Build eXist for Cocoon:
   ./build.sh -f build/scripts/cocoon/build.xml
7. Clean the Cocoon build tree using the Cocoon build.sh:
   ./build.sh clean
8. Rebuild Cocoon:
   ./build.sh
9. Copy missing jar files:
   ws-commons-util-1.0.2.jar
sunxacml-1.2.jar
   from EXIST_HOME/lib/core into the generated
   COCOON/build/webapp/WEB-INF/lib
10. Copy some custom jars of our own, xqSearchUtils.jar and TitleSortComparator, along with SaxonHE.jar, into the Cocoon lib directory -- not part of the core process.

This gives us Cocoon 2.1.11 with eXist as a block, with a working admin interface and a working JNLP client. Eventually, I suppose step 9 will be redundant as those jars will be handled along with the others as part of the normal build.

Meanwhile, these steps are also going to be needed to really refine the process:

1. Abstract hard-coded paths from the script.
2. Patch the root sitemap in Cocoon to add the Saxon 9 XSLT 2 generator, and a couple of other generators we like to use.
3. Figure out the implications of the build source and build target settings. In my successful build this morning, I built with 1.5, 1.5, although the deployment environment will be 1.6.

Greg and I have been working on setting up an automated system for building eXist from SVN trunk and then making a Cocoon package. The script I've got is basically working (assuming the SVN checkout is not broken, which it sometimes is), but it does involve some patching of files which we've learned about by trial and error, and the Cocoon webapp that it builds doesn't seem to successfully start eXist up. This is a painful process, but if in the end we manage to make it work, we'll be able to file bug reports and patches that get into the trunk, making it much easier to build a Cocoon block version in future, and we'll also gain enough understanding of the process to debug future problem. If we can easily build a distro from the SVN trunk, we can be regularly testing our projects on future versions and preparing them for migration, which is going to be essential. Meanwhile, the old version stumbles along, requiring two or three restarts every day...

Heavily used cocoon sites (like the ISE) tend to generate very large cache files ($CATALINA_HOME/work/Catalina/localhost/_/cocoon-files/cache-dir/cocoon-ehcache-1.data) which eventually fill the filesystem and create headaches.

The ISE site is now using a modifed cocoon.xconf ($COCOON_HOME/WEB-INF/cocoon.xconf)to manage this problem. Around line 558 there was a stanza like this:

  <store logger="core.store">
    <parameter name="maxobjects" value="${store.maxobjects}"/>
    <parameter name="use-cache-directory" value="true"/>
  </store>

Which has been changed to this:
  <store logger="core.store">
    <parameter name="maxobjects" value="${store.maxobjects}"/>
    <parameter name="use-cache-directory" value="true"/>
    <parameter name="eternal" value="false"/>
    <parameter name="timeToLiveSeconds" value="0"/>
    <parameter name="timeToIdleSeconds" value="3600"/>
  </store>

So far (in the last 24 hours) the cache seems to behaving and the site isn't crawling, so it looks like we're on the right path.

From an eXist list posting:

The error damages the indexes. To recover from it, you would need to 
stop the db, remove all .log and .dbx files except dom.dbx, symbols.dbx 
and collections.dbx, restart the db and use the Java admin client to 
reindex everything.

This free Windows anti-virus app left beta yesterday. Tested it on my Windows 7 VM -- works fine. Now I'm installing it into my workaday XP VM (the image of my old computer), which I still use for a lot of key tasks. Fingers crossed...

KSW was having trouble running oXygen on Karmic (Ubuntu 9.10). Keystrokes would not generate characters in the editor for a second or two after being hit. The oXygen help file provided the solution:

Display problems like screen freeze or momentary menu pop-ups during mouse movements over screen on Linux or Solaris can be solved by specifying the parameter

-Dsun.java2d.pmoffscreen=false

for the Java virtual machine. This parameter disables off-screen pixmap support and must be added to the Java command line which starts the Java virtual machine at the end of the file oxygen10.3 located in the install directory.

We added this to both the oxygen and oxygen.sh files, grouping it with other similar parameters, and remembering to put quotes around it where required.

Greg and I spent a little time looking at options for an online booking system that Judy can use to handle booking of the lab workstations. We settled for the moment on MRBS, and open-source PHP/mySQL system which seems simple and easily configurable. We set it up and started testing it. It's intended to be used for room bookings, with rooms divided into areas, but since all the text on the pages comes from a language file we were able to customize it to handle computers in rooms instead of rooms in areas, very simply, just by editing the language file. The resulting booking calendar seems to be nicely printable, and the CSS is centrally configured via a PHP system which abstracts the settings into variables which are used to construct the stylesheet. We'll probably want to write our own stylesheet when we get comfortable with it, because it's not terribly pretty, but it's certainly usable out of the box.

Pros:

• Lovely clean code.
• Really well commented.
• Documentation is sufficient and clear.
• DB structure is very straightforward.
• UTF8 support.
• Good separation of concerns (page generation, CSS, GUI strings, etc.).

Cons

• HTML 4.01 (could be rewritten in XHTML, but would be tiresome and provide little benefit).
• Not so pretty (yet).