This is what I had to do to get WASP working on my Windows 95 machine (mcmeric).

Thrashed

Tried to get an off the shelf servlet server from O'Reilley, which they do indeed have for their website Pro product, but I couldn't bear to get involved in what is, they say, a time limited trial.

Installed http://www.livesoftware.com/pub/release/jrun221.exe , an url which was emailed to me after I had given of my precious details :(

I was unable to get much further down this road, as it looked like I was going to have to backward engineer the website-pro 30 day trial into allowing the website 1.1 to run jrun, and anyway I didn't like the tone of the jrun licence.

Decided to look at apache where there was a Win32 apache installation which slipped in like a dream; so byebye website ;) (the only time consuming thing was getting cgi-scripts to run, as apache takes notice of the shebang, whereas website, poor fools, use the registery associations).

So I got jserv, from apache, but I think from javasoft originally.

This will not install without

To install Apache JServ 1.0b1 on this system the following requirements must be met at this moment:


1) The Apache Web Server 1.3.3 or higher must be installed and correctly configured in a local and accessible directory.

2) Any Java Virtual Machine 1.1 compatible must be properly installed.

3) The JavaSoft Java Servlet Development Kit 2.0 (JSDK 2.0) must be installed.


If any of these requirements are not met at this moment, Apache JServ 1.0b1 may not be installed correctly.

Somewhere along the line I had obtained jdk-116win32.exe, so installed that.

Then got the jsdk and installed it, oddly enough I had to restart my jserv installation, but didn't bother to restart computer.

Continued with the jserv installation

The Jserv licence looks friendly:

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the Java Apache Project for use in the Apache JServ servlet engine project (http://java.apache.org/)."

4. The names "Apache JServ", "Apache JServ Servlet Engine" and "Java Apache Project" must not be used to endorse or promote products derived from this software without prior written permission.

5. Products derived from this software may not be called "Apache JServ" nor may "Apache" nor "Apache JServ" appear in their names without prior written permission of the Java Apache Project.

6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes software developed by the Java Apache Project for use in the Apache JServ servlet engine project (http://java.apache.org/)."

THIS SOFTWARE IS PROVIDED BY THE JAVA APACHE PROJECT "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE JAVA APACHE PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

This software consists of voluntary contributions made by many individuals on behalf of the Java Apache Group. For more information on the Java Apache Project and the Apache JServ Servlet Engine project, please see .

Jserv however buggered up the apache httpd.conf, so apache would no longer start, as it could not load modules/ApacheModuleJServ.dll.
Looking at the howto it looks as though one is not expected to be able to install the .dll straight out of the box but must compile it yourself using MS VC++ 5, which of course I haven't got.

Java

JDK

Installation

All I did was unpack it into /usr/local/packages/inst/jdk117_v1a and make symbolic links from /usr/local/bin to all their commands in .../jdk117_v1a/bin/. (Alternatively you could add .../jdk117_v1a/bin/ to your PATH. The coolest way to do that is creating a file in /etc/profile.d/.) You don't have to mess around with CLASSPATH or whatever.

Other VMs

RedHat ships with rather an old Kaffe. The newest Kaffe (1.0-b2) seems almost to work with JRun, the problem (as revealed by strace) being that JRun uses serialisation to save its session state in a Hashtable. Serialisation of Hashtables in particular is the subject of some cussing in the Kaffe Known Bugs FAQ. JRun goes into exactly the infinite loop mentioned there.

There are other JIT VMs than kaffe. Furthermore Sun is ``working closely'' now with the Linux-Java people on the JDK which will perhaps have one.

My favourite idea is to make the whole thing a proper executable using gcc's Java backend ...

Servlet runner

JRun

JRun isn't really very free. The license would, on the face of it, allow us to use it on Paneris but not on customer sites.

I don't think Sun's thing is free either. I don't know how much it time it would take to make an open source servlet server (Mr WASP thinks not long). However it seems to me that we don't actually need one, since you could achieve functionally the same result with a plain CGI interface talking to a simple custom server.

Installation

I unpacked it in /usr/local/packages/inst (it unpacks as jrun/...). The scripts in jrun/2.2/jsm-default (startjsm, stopjsm, startadmin) need telling what the java VM command is, in environment variable JAVA_BIN. Also note that you have to be in that directory jrun/2.2/jsm-default when you run ./startjsm (not brilliant but would be easily fixable if that wasn't illegal ...).

http://archives.java.sun.com/cgi-bin/wa?A1=ind9901&L=servlet-interest

Web server

Apache

JRun will work as a simple web server on its own, but I expect we want to use it via Apache. To do this you need to build Apache from source with JRun's Apache ``connector'' included.

Installation

As (vaguely) instructed in JRun's jrun/2.2/connectors/apache/INSTALL.TXT, I copied jrun/2.2/connectors/apache/src to apache_1.3.3/src/modules/jrun in the Apache source tree. Then I ran Apache's ``configure'' script as instructed in their INSTALL, but with the extra --enable-module=src/modules/jrun/libjrun.a mentioned in JRun.

When it came to running the make, I found that JRun's connector wouldn't compile on Linux without an extra #include <sys/time.h> in jrun_proxy.h.

I even remembered to stop the old Apache (e.g. /etc/rc.d/init.d/httpd stop) before starting the new one!

Database

PostgreSQL

I couldn't see any JDBC drivers in the RedHat installation, so I downloaded the new PostgreSQL 6.4 (which has significant advantages like the much easier autoincrement).

Compilation

Amazingly, it wouldn't quite compile---I had to comment out line 44 of postgresql-v6.4/src/backend/port/strtol.c (they try to bypass the problem of ```standard'''-library compatibility between Unixen by shipping their own; the only trouble is that the haven't bothered to make the const declarations match those of the target system's header files!).

Installation

Installation is really very long-winded, though fully documented in INSTALL and I am sure one is better off with an .rpm. Not impressed. Anyway I copied the JDBC driver, which simply takes the form of a 133kb .jar, and put it in my CLASSPATH.

Other databases

There is no problem here since everything works with JDBC.

WASP

Installation

The WASP tarball contains only a Java source hierarchy org/wasp/.... I unpacked that in /usr/local/packages/inst/wasp-0.8, but made a symbolic link to wasp-0.8 from wasp (a good thing to do since if you then always access WASP through wasp, upgrading is simply a matter of changing the link).

Compilation

There are two package hierarchies missing from the vanilla JDK which WASP expects to find: javax.servlet.*. and com.sun.java.swing.*. Luckily both are included with JRun (in fact it's just a matter of a few interfaces which are easy enough to forge).

So to compile it I had to

  cd /usr/local/packages/inst/wasp-0.8
  export CLASSPATH=.:/usr/local/packages/inst/jrun/2.2/lib/jrun.jar:/usr/local/packages/inst/jrun/2.2/classes
  javac `find -name '*.java'`

Merely compiling the obvious top-level source org/wasp/engine/Servlet.java turned out not to be enough (I got ClassNotFoundExceptions . I suppose it's always safest to compile everything in sight!

There was one error because one of the .javas is a test of the Oracle JDBC driver (would be nice ...) but it can safely be ignored.

Installation

To install a servlet for use through JRun you have to put its package hierarchy under jrun/2.2/jsm-default/services/jse/servlets/. I just made a symbolic link from there to /usr/local/packages/inst/wasp/.

Configuration

You have to tell WASP where its templates live and what the predefined data sources are. That's done in the JRun file jrun/2.2/jsm-default/services/jse/properties/servlets.properties. I added the lines

  servlet.wasp.args=filePath=/home/williamc/gash,errorPage=/error.html,daoFoo=uk.co.paneris.Foo
  servlet.wasp.code=org.wasp.engine.Servlet
  servlet.wasp.preload=true

This tells JRun that wasp is an alias for the servlet org.wasp.engine.Servlet with the given arguments filePath etc.

It will look for templates in /home/williamc/gash; error.html in that directory is that page returned when something goes wrong (I'm sure there are template variables that could help you say what it was but I don't know what they are).

To get JRun to pass .wasp files through WASP you add the line

  *.wasp=wasp

to jrun/2.2/jsm-default/services/jse/properties/rules.properties. It's possible also to run it from a /servlet/wasp URL, much like /cgi-bin/..., but WASP doesn't react very sensibly to that.

Running it

Here is my test page /home/williamc/gash/hello.wasp:

  <HTML>
  <BODY>

  <tl:DATA name="FooName">
  <tl:INPUT name="method">Bar</tl:INPUT>
  <P>It's &BAR;</P>
  </tl:DATA>

  </BODY>
  </HTML>

This means ``Ask for the data access object which registered itself at WASP startup with name FooName'' (which my test DAO Foo does). ``Call its daoBar method to get the result set. Show the column named bar from each row.'' (The &BAR; has to be in capitals.)

Here is the source for Foo, shamelessly borrowing from his JDBCTest example:

  package uk.co.paneris;

  import org.wasp.data.*;
  import org.wasp.engine.*;
  import java.util.*;
  import javax.servlet.*;
  import java.sql.*;

  public class Foo extends DataAccessObject {

    private Statement s;

    public String getName() { return "FooName"; }

    public void init(ServletConfig config) {
      try {
        Class.forName("postgresql.Driver");

        Connection conn = DriverManager.getConnection("jdbc:postgresql:williamc?user=williamc&password=dummy");
        s = conn.createStatement();
      }
      catch (Exception e) {
        e.printStackTrace();
        throw new RuntimeException();
      }

      DataRegistry.getInstance().registerDataAccessObject(this);
    }

    public boolean initialized() { return true; }

    public RowResultSet daoBar(Hashtable h, Request r, MarkupNode m) {
      try {
        return new SqlRowResultSet(s.executeQuery("SELECT bar FROM foo"));
      }
      catch (Exception e) {
        e.printStackTrace();
        throw new RuntimeException();
      }
    }
  }