I have the more-or-less official JDK 1.1.7 v1a installed. This is a straight Linux port, with very little help from Sun, of the Solaris reference implementation. It is not bang up to date with the 1.2 beta and it doesn't have a JIT compiler.
Things should be better very soon since Sun have decided that Linux is a good thing for them (time will tell ...).
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.
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 ...
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.
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 ...).
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.
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!
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).
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 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.
There is no problem here since everything works with JDBC.
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).
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.
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/.
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=trueThis 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=waspto 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.
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();
}
}
}