 |  |
| |
Go to http://xml.apache.org/cocoon/index.html for an introduction to Cocoon and a link to the download page. You will see that a number of mysterious entities are mentioned: Xerces, Xalan, FOP, Xang, SOAP. These are all subsidiary packages that are used to make up Cocoon. What you need of them is included with the Cocoon download and is guaranteed to work, even though they may not be the latest releases. This makes the file rather large, but saves problems with inconsistent versions.
If you are running Win32, download the zipped executable; if Unix, then download the sources. We got Cocoon-1.8.tar.gz, which was flagged as the latest distribution.
As usual read the README file. It tells you that the documentation is in the .../docs subdirectory as .html files — what it might mention, but did not, is that these files are formatted using fixed-width tables for a wide screen and, if you want hardcopy, don't print out well. They are not easy to read either, so more flexible versions, suitable for reading and printing, are in the .../docs.printer subdirectory. There is a snag, which appeared later: the printable files are completely different from the screen files and omit a crucial piece of information. Still, as the reader will have gathered, this is normal stuff in the world of Java.
What follows is a minimum version of the installation process.
It seemed sensible to read install.html. Since Cocoon is a Java servlet, albeit rather a large one, you need a Java virtual machine, v1.1 or better. We had v1.1.8. If you have v1.2 or better, you need to treat the file <jdk_home>/lib/tools.jar, which contains the Java compiler, as a Cocoon component and include it in your classpath. This meant editing .login again (see Chapter 18) to include:
setenv CLASSPATH "/usr/src/java/jdk1.1.8/lib/tools.jar:."
We have to make Cocoon and all its bits visible to JServ by editing the file: usr/local/bin/etc/jserv.properties. The Cocoon documentaion suggests that you add the lines:
wrapper.classpath=/usr/local/java/jdk1.1.8/lib/classes.zip wrapper.classpath=/usr/src/cocoon/bin/cocoon.jar wrapper.classpath=/usr/src/cocoon/lib/xerces_1_2.jar wrapper.classpath=/usr/src/cocoon/lib/xalan_1_2_D02.jar wrapper.classpath=/usr/src/cocoon/lib/fop_0_13_0.jar
Of course these paths were not correct for our machine. In JDK 1.1.8 there is no tools.jar, so we used classes.zip. Do not add servlet_2_2.jar, or Cocoon will not work. You should find a location in the jserv.properties file that already deals with "wrappers," so that would be a good place for it.
Next, we are told:
At this point, you must set the Cocoon configuration. To do this, you must choose the servlet zone(s) where you want Cocoon to reside. If you don't know what a servlet zone is, open the zone.properties file.
We opened usr/local/bin/etc/zone.properties. The file has a lot of technical comments in it, which would make sense if you knew all about the subject. It would be overstating things to say that we instantly learned what a "servlet zone" is. The instructions go on to say that we should add the line:
servlet.org.apache.cocoon.Cocoon.initArgs=properties=[path to cocoon]/ bin/cocoon.properties
As is normal with anything to do with Java, the advice is not quite accurate. There was no .../bin/cocoon.properties in the download. The file appeared (identically, as tested by the Unix utility diff) in two other locations, so we copied one of them to /usr/local/bin/etc (where all the other configuration files are) and added the line:
servlet.org.apache.cocoon.Cocoon.initArgs=properties=/usr/local/ bin/etc/cocoon.properties
at the bottom of the zone.properties file.
Finally, we had to attack the jserv.conf file. We set ApJServLogFile to DISABLED, which sends JServ errors to the Apache error_log file. We were also told to add the lines:
AddHandler cocoon xml Action cocoon /servlet/org.apache.cocoon.Cocoon
where "/servlet/ is the mount point of your servlet zone (and the above is the standard name for servlet mapping for Apache JServ)."
These are, of course, Apache directives, operative because the file jserv.conf is included in the site's Config file. It was not very clear what was this was trying to say, but we copied these two lines literally into jserv.conf — within the <IfModule mod_jserv.c> block.
Apache started cleanly (check the error log), but an attempt to access http://www.butterthlies.com/index.xml produced the browser message:
Publishing Engine could not be initialized.
java.lang.RuntimeException: Can't create store repository: ./repository. Make sure
it's there or you have writing permissions.
In case this path is relative we highly suggest you to change this to an absolute path
so you can control its location directly and provide valid access rights.
at org.apache.cocoon.processor.xsp.XSPProcessor.init(XSPProcessor.java:194)
....Since the "repository" is defined in zone.properties as:
repositories=/usr/local/bin/servlets
the problem didn't seem to be a relative path, so it was presumably the write permission. We changed this by going up a directory and executing:
chmod a+w servlets
After a restart of Apache, this produced the same browser error. After further research, it appeared that, in true Java fashion, there were at least two completely different things called the "repository." The one that seemed to be giving trouble was specified in cocoon.properties by the line:
processor.xsp.repository=./repository
We changed it to:
processor.xsp.repository=/usr/local/bin/etc/repository
and applied:
chmod a+w repository
This solved the Engine initialization problem, but only to reveal a new one:
java.lang.RuntimeException: Error creating org.apache.cocoon.processor.xsp. XSPProcessor: make sure the needed classes can be found in the classpath (org/apache/ turbine/services/resources/TurbineResourceService) ...
This stopped us for a while. We looked in the configuration files for some command involving a "turbine" in the hope of commenting it out and failed to find any. Then we noticed that in cocoon.properties the word "turbine" appeared in comments near a block of commands clearly involving database stuff. Perhaps, we thought, the problem was not that "turbine" should be deleted, but that something else in Cocoon wanted a "turbine," even though there was no database to interface to, and couldn't get it. We found a file /usr/src/cocoon/lib/turbine-pool.jar and added the line:
wrapper.classpath=/usr/src/cocoon/lib/turbine-pool.jar
to usr/local/bin/etc/jserv.properties.
To our surprise Cocoon then started working. To be fair, the unprintable original installation instructions did mention turbine-pool.jar and said it was essential. However, the printable version, which we used, did not.
When you wrestle with this stuff, you will probably find that you have to restart Apache several times to activate changes in the Cocoon steup files. You may find that you get entries in the error_log:
... Address already in use: make_sock: could not bind to port 80
This is caused by restarting Apache while the old version is still running. Even though the JServ component may have failed, Apache itself probably has not and won't run twice binding to the same port. You need to kill and restart it each time you change anything in Cocoon.
|  | |
| 19.3. Cocoon |  | 19.5. Cocoon 2.0.3 and Tomcat |
Copyright © 2003 O'Reilly & Associates. All rights reserved.