The Nun.Me.Shu framework is a completely standard implementation of the basic XML and XSL specifications. No hosting-specific extensions are used. It can therefore be deployed in any environment that can render XML with XSL.
The Nun.Me.Shu web site is hosted in a standard Java environment with Cocoon2 XSLT servlet and Tomcat servlet container. Both are part of the Apache community of open-source software projects, and can be downloaded for free from the Apache web site.

The hosting components in my development environment are:

• Java JVM 1.2.2
  A Java Virtual Machine is needed for Tomcat and Cocoon.
• Cocoon 2.0.3
  Cocoon is an XML publishing framework, designed for performance and scalability around pipelined SAX processing, with a sophisticated caching system. Cocoon is a Java servlet and thus depends on a servlet engine, like Tomcat.
• Tomcat 4.0.4
  Tomcat is a servlet engine, which can also be used as a stand-alone web server. In a development environment, using Tomcat as a web server is convenient and just fine.
• Xalan-J 2.2.0
  Xalan is the XSLT processor used by Cocoon. My download of Cocoon came with a buggy version of Xalan (see the history page), forcing me to separately download and install an older stable version of Xalan.
• Apache web server
  Apache is a stable, robust web server. I don't have it installed in my development environment since Tomcat doubles as a web server there. In a production environment however, Tomcat should be used just as a servlet engine, and Apache should be used as the web server.

My development environment is a Sony Notebook with Windows 2000. Configuration details below are based on the Windows operating system. The live web site is hosted on a Linux operating system. Besides from a slightly different directory structure (and the additional installation of the Apache web server) the configuration on Linux is pretty much the same as outlined here.

Download
Downloading of the Java JVM, Tomcat binary distribution, Cocoon2 binary distribution and Xalan-J binary distribution, and installing it on your local machine is simple and straightforward (simply unzip the downloaded files into their default directory and create a few required environment variables; the installation documentation provides the details).

Install Cocoon under Tomcat
Cocoon's cocoon.war file then has to be copied into Tomcat's webapps directory and the main part of the installation is done. You should now be able to start Tomcat as a web server and access Cocoon's test and documentation pages through your browser. When you start Tomcat it will deploy the cocoon.war file and create a directory named cocoon in its webapps directory.

Create web site and copy basic configuration files
Next create a directory for your web site. Copy the file sitemap.xmap and the directory WEB-INF from Tomcat's webapps\cocoon directory to your web site directory. This contains the basic configuration of Cocoon for your web site, and has to be edited later (see below). Now copy all Xalan jar files from Xalan's bin directory to your web site's WEB-INF/lib directory, and delete equivalent existing versions that were there before (since the goal is to replace the buggy version of Xalan that came with the Cocoon distribution with the older stable version of Xalan that was downloaded separately).

Directory structure
The relevant part (from a configuration point of view) of the directory structure on my Notebook looks like:

After the basic installation of Tomcat and Cocoon is done (and tested, by starting the server and accessing Tomcat's and Cocoon's documentation through your browser) you'll have to configure both to be able to render XML pages from your web site.

Edit virtual host configuration
By default, Tomcat expects applications and web sites to reside in its webapps directory. But I wanted to be independent of whatever web server or servlet engine I was using, and thus I kept my web pages in their own directory structure (outside the Tomcat directory). Tomcat supports this but it requires editing of its server.xml file (in Tomcat's conf directory). Within the default virtual host element <Host name="localhost" ...> of server.xml I added/edited the following lines [view complete file]:
Note that by default, Tomcat's documentation is at the root of the localhost, but I wanted the nunmeshu web site there. The second Context element in above code snippet therefore redefines the path for the Tomcat documentation.

With this change I can now access the following local sites through my browser:

Edit servlet deployment descriptor for Cocoon
After the basic installation, outlined above, your web site's WEB-INF directory contains a web.xml file (copied from Cocoon). This is the servlet deployment descriptor for Tomcat, which specifies parameters for the Cocoon servlet, specific for your web site. It is used by Tomcat in addtion to its default web.xml file (in Tomcat's config directory). I left the default parameters in the <servlet> element untouched but changed the part below that. I defined servlet mapping based on file extensions, in stead of based on a directory path, since I want Cocoon only to handle XML-related files, and leave Tomcat to serve images, CSS files and such. I also added a mime-mapping for extension xml-source, which is used in the Nun.Me.Shu architecture next to the regular xml extension. Here are my edits [view complete file]:

Delete temporary files
Tomcat has the habbit of creating a lot of temporary files (28MB) each time it is started, without deleting them when the server is stopped. This can quickly fill your hard drive if you are not aware of it. I therefore appended some code to Tomcat's stop-start script, catalina.bat (in Tomcat's bin directory), that will delete these temporary files, and in addition clear the Cocoon cache [view complete file]:

After the basic installation, outlined above, your web site's base directory contains a sitemap.xmap file, and your web site's WEB-INF directory contains a cocoon.xconf and logkit.xconf file (all copied from Cocoon). These are the main configuration files for Cocoon specific to your web site.

Edit sitemap file
The sitemap.xmap file in your web site's base directory is sometimes refered to as the "heart of Cocoon". It contains instructions for Cocoon how to process XML files. The sitemap file is rather big and consists of the following sections: components, views, resources, action-sets and pipelines. I left all but the pipelines section untouched. The pipelines section contains the specific instructions how to process XML content, and thus is important and specific to your web site. I deleted the existing default pipelines sections and replaced it with the following [view complete file]:
Note that the first two pipelines mount another sitemap. Both featured sites on the Nun.Me.Shu web site have their own sitemap. This was not necessary, but I was curious how it worked, and it allowed me to keep those featured sites completely independent of the main site.
The third and last pipeline instructs Cocoon how to process XML files on the main site. It has two pattern matches: requests for files with names ending in "xml" take that XML file and process it with the main stylesheet; requests for files with names ending in "xml-source" also take the original XML file but now process it with a special stylesheet (cp.xsl) that simply copies the XML source to the output.

Edit configuration file
The cocoon.xconf file in your web site's WEB-INF directory is the main configuration file for Cocoon. I left it untouched, except for commenting out the <hsgldb-server> section, which was causing "port in use" errors when Tomcat was started [view complete file]:

Edit logkit file
The logkit.xconf file in your web site's WEB-INF directory contains the location of the various log files for Cocoon, and allows for different levels of verbosity of the log messages. I left it untouched, but you might want to turn all logging off if performance is an issue in your environment. [view complete file]

When you have installed Apache as the web server (in stead of Tomcat), it has to be configured such that it will forward requests for XML files to Tomcat/Cocoon. This is specified in Apache's httpd.conf file in an IfModule directive within your site's virtualhost configuration:

Because the site was producing some 505 errors from time to time, and because sometimes the Tomcat servlet engine was down for a longer period of time (both related to the fact that the hosting environment is more or less experimental), I decided to pre-generate the static pages of the site and only render the web services pages real-time. For this I defined a conditional redirect in the .htaccess file in the web site's root directory:

Basically what happens is as follows:
The first RewriteCond tests if the requested URL has a .html extension.
If the first test is successful then the second RewriteCond tests if the requested file does not exist.
If the second test is successful (and thus there is no .html file) then the RewriteRule is executed: this replaces the .html extension with a .xml extension, and thus the XML file will be requested, and rendered real-time.
This allows all web pages to be referenced as .html pages. All static pages of the site are pre-generated as HTML files and thus will be served by Apache. Only the dynamic pages (the web services pages) have no corresponding HTML file, and thus they will be rendered appropriately. Note that the browser address window will still show a filename with a .html extension, but the file that is accessed in reality is the file with a .xml extension.
In short, if a filename with .html extension is present it will be served, otherwise the corresponding file with .xml extension will be rendered:
   - suppose there is a request for foo.html.
   - if file foo.html exists, then Apache will serve the file.
   - if file foo.html does not exist, then Apache will redirect to foo.xml which subsequently will be served by Cocoon.
So, simply by pre-generating or deleting html files one can control if a page is rendered or served from file cache.
Note that the .htaccess file has to be in the web site's root directory, otherwise the RewriteRule will fail (because the filename there is resolved relative to the directory the .htaccess file is in).