In operation, it looks something like this:
The application does not talk directly to any X10 hardware, but uses the `java.x10' API; this API is a vendor-independent implementation of the X10 command set in Java. It requires a java.x10-compliant driver; somewhere in this package is a driver for the `twseriald' automation server, which in turn drives a TW723 two-way controller. The driver architecture is straightforward, and it should not be difficult to implement drivers for other hardware
This application requires a J2EE-compliant JSP engine. I have tested it with Sun's J2EE Reference Implementation and Tomcat 3.2.1. In theory it will work with any J2EE JSP engine, but there may be issues with making the driver classes available.
For this application to work, the JSP engine must be able to find, in addition to the JSP pages and static content in this package, the classes for the javax10 API (typically package in x10api.jar) and the classes for the driver. The Reference Implementation packages these up into the EAR file along with the application components, and uses the `manifest classpath' setting to tell the server where to find them. Not all JSP engines support this technique, and you may need to tweak its classpath manually.
The operation of the application is, I believe, self-explanatory
There are various variables that must be set in the file `defs.jsp' deploying the applications.
driver (mandatory). The class that forms the driver for the X10 hardware or server
url (mandatory). The URL used by the X10 driver to locate the server
username Username for access to the controller, if used
pass Password corresponding to the username
defaultHousecode The housecode (expressed as a number 1-16) that will be in effect the
first time the application starts. After this, it is set using buttons on the display.