Create the webapp directory

Since the configuration files have to be modified an exploded WAR has to be used. The webapp directory has to be created and the WAR will be extracted inside of it.

mkdir xwiki && cd xwiki
unzip ../xwiki.war
rm ../xwiki.war

Create and configure a database

Create a database including a dedicated database user. Open the file WEB-INF/hibernate.cfg.xml and uncomment the MySQL block. Modify the following properties:

• connection.username
• connection.password
• connection.url

Important: Don’t forget to add the MySQL JDBC driver to your classpath (e.g. WEB-INF/lib).

Note: It is of course also possible to use a container managed DataSource via JNDI.

Configure Logfile

Since the security manager restricts file IO to the webapp directory the logging has to be reconfigured. To do so the log4.properties file has to be copied from xwiki-core-2.0-milestone-4.jar to the WEB-INF/classes directory. After this the property log4j.appender.file.File has to be modified to point to a writeable path.

Add the context file to Tomcat

Add a file name ${context}.xml to the /conf/Catalina/localhost” directory of $CATALINA_HOME (the Tomcat instance) and put the following content into it:

<Context path="${contextPath}" docBase="${pathToWebapp}" ></Context>

Eventually put in references to resources like DataSource’s etc.

Create the proxy settings in Apache HTTPD

You can use any proxy settings. I’m currently using a very simple setup:

<Proxy ajp://localhost:10709*>
  Allow from all
</Proxy>

RewriteEngine On
RewriteRule ^/$ /xwiki/ [R=301,L]

ProxyPass        /      ajp://localhost:10709/
ProxyPassReverse /      ajp://localhost:10709/

Note: xwiki is the contextPath

Test the installation

Surf to http://www.yourdomain.com/. An empty XWiki page should be displayed. The first step should always be to register a user so the administration area is accessible. The default content can be imported by using the page /${contextPath}/bin/import/XWiki/XWikiPreferences.

I’ll probably blog more about XWiki and how to customize it in the future.

I must admit that I always had some kind of a love-hate relationship with Tomcat. The classloader had some bad issues when reloading a webapplication too often and often killed the complete server. Taking down all of the other webapplications too. Although this has gotten a lot better recently it’s still bothering me a bit.

Since I had some time after my last project I started investigating other open source alternatives. I often heard of Jetty, praised for it’s speed and simplicity, it seemed like a great alternative and I played around with it a bit. I really liked it since it was simple to use and easy to deploy but as I started to google for things like performance measurements or how to use it with a security manager I didn’t really found a lot of documentation (compared to Tomcat) and the performance doesn’t really doesn’t seem to differ from Tomcats.

So I’m once again going the Tomcat route. It has a big community and is even used in military and government organizations. It’s really not a technology decision (although I think Tomcat is solid) but more political thinking.

It will also save me some time which I can invest in trying out other technologies. Meow…