Tapestry Frequently Asked Questions

Last updated 4/25/2004

Q: My run-tests fails on test-javadoc, what's wrong?
A: This is my bad. I forgot to remove the javadoc reference to a class that was removed from the distribution. I've updated it in the downloadable distribution. If you downloaded either tapestry-2.0.tar.gz or tapestry-2.0.zip, download it again, and you'll get 2.0.1, which includes the minor fix to allow the tests to proceed. You can also skip ahead to any test (they're run in alphabetical order) by running run-tests as "run-tests -s TestToSkipTo".

Q: Why are my regression tests failing silently?
A: If you do a run-tests, and you see nothing, try running test-ostore.tapestry.dynamic by itself. If this produces the following:

pond/regression> test-ostore.tapestry.dynamic
readline() on closed filehandle Toolbox::IN at Toolbox.pm line 281.
readline() on closed filehandle Toolbox::IN at Toolbox.pm line 281.
readline() on closed filehandle Toolbox::IN at Toolbox.pm line 281.
readline() on closed filehandle Toolbox::IN at Toolbox.pm line 281.
readline() on closed filehandle Toolbox::IN at Toolbox.pm line 281.
readline() on closed filehandle Toolbox::IN at Toolbox.pm line 281.

Then the problem is that you did not set your OSTOREHOME variable correctly. OSTOREHOME should be set to the parent directory where you install the distribution into (e.g. if the code sits in /usr/home/ravenben/oceanstore/pond, then set OSTOREHOME=/usr/home/ravenben/oceanstore).

Q: Why do I get an NoSuchClassDefException when running the tests?
A: This may be due to the run-java script overwriting your CLASSPATH environmental variable at run time. Check to make sure that run-java appends, but does not simply overwrite the CLASSPATH variable. run-java sits inside the pond/ostore directory.

Q: Why does sandstorm not compile correctly?
A: This could be from one of many configuration reasons. First, make sure you have IBM Java JDK installed, and that $IBMJDKPATH/jre/lib/rt.jar is included in your CLASSPATH setting. Next, check to make sure that the sandStorm configure program picks up the IBM JDK directory. Do this by watching for the line:

checking Installation path of JDK...

If this is followed by any directory other than the home directory of IBM JDK, go into mdw/util/jni and mdw/nbio/jni and edit the configure file. Insert the following line before line 603 in both of these files:

ac_cv_java_home=(Substitute your IBMJDK homedir here)

Q: My tests fail, and I see at the top of the failed output:
Stopping - Timed out. What gives?
A: This means that the regression test terminated waiting for some step in the test to complete. This can happen in a number of instances, most of which involve some sort of firewall blocking ports 3630 to 3636, which are the ports used by the Tapestry regression test. Please make sure that whether you are running the Tapestry test or your own Tapestry application, the correct ports are opened in your firewall for messages to be delivered. Also make sure that your local machine name is set to the actual DNS name of your machine, so that Tapestry nodes can use name resolution to find the localhost's IP address.

Q: I'm doing a recompile of the sandStorm tree or other parts of the Tapestry distribution on an SMP using IBM JDK, and local machine load skyrockets. Why?
A: This is a strange occurence we also came across while testing the Tapestry distribution. We haven't tracked down the exact source, but it seems to occur only on Linux SMP kernels with IBM JDK. If this happens to you, switch to Sun's JDK, and everything should go smoothly.

Q: What are the TapestryQuery and TapestryQueryResult interfaces, and how do I use them?
A: TapestryLocateMsg can be used naively or to embed very complex queries. The way that Interweave uses it is the normal/naive way. You send a TapestryLocateMsg with a destination ObjectID, and it sends it to the first object it locates with that ID.
Alternatively, you can send in an optional TapestryQuery object, you'll have to create your own, since TapestryQuery is just an interface. The interface includes a "query()" method that is called whenever the TapestryLocateMsg arrives at a node that contains matching pointers. You can do whatever you want inside the query() method, and you should return a TapestryQueryResult object (again implement your object that follows the interface), and depending on what you put inside the TapestryQueryResult, Tapestry will do different things. For example, you can choose your own matching results out of what Tapestry sees at that local node, and put them into the fields inside your TapestryQueryResult, along with a boolean that tells Tapestry whether you want the TapestryLocateMsg to continue onwards towards the root node (if you're not satisfied with the current set of object replicas that you see).
In general, TapestryLocateMsg is just used to establish where a communication endpoint is (much like a rendevous mechanism). So the reply to the TapestryLocateMsg is generally a TapestryRouteMsg (which is just a normal point to point communique).