These tips cover JumpStart 5.8.n.

Some other excellent resources are the Tapestry 5 How-To Page, and the Tapestry User mailing list which is archived and searchable at nabble and gmane. Also, the book Tapestry 5: Building Web Applications by Alexander Kolesnikov, although it is getting very out of date.


JVM options.

Editing .tml files.
Use Loom.


Testing: WAR or EAR?
Unit tests.
Integration tests.
The database.
Viewing and editing data.
Logging SQL and Hibernate.

Altering the database schema.
Rebuilding the database and schema.

Other database brands.
Creating a fresh project.

Other servers:
  JBoss 6.1.0, 6.0.0, or 5.0.1
  GlassFish 2.1.1
  Tomcat 5.5 or 6.0



  • Set JVM options:
    • When running Jetty we already set several JVM options, including -Dtapestry.production-mode=false and
      Here are some to consider:
      -Dtapestry.production-mode=false Tells the Tapestry ExceptionReport page to display full details of the exception, which is great during development. When set to true (which is the default since T5.0.10), Tapestry's ExceptionReport page will display an abbreviated report so as to avoid disclosing details of your application's internals. See Configuring Tapestry.
      -Dtapestry.compress-whitespace=false Tells Tapestry not to compress whitespace as it generates a page from a template. Makes the generated page source much easier to read eg. when you tell your browser to display the page source. See Configuring Tapestry. Necessary for JumpStart initially, and great during development, but
      NOT RECOMMENDED IN A PRODUCTION ENVIRONMENT because data can be lost. Tells Hibernate to automatically bring the database structure into line with the app's entity definitions at every restart. See hibernate optional configuration properties.
      -Xmx192m Gives more memory for the heap, avoiding "out of memory" errors. See JVM options.
      -XX:MaxPermSize=96m Gives more Perm Gen memory. If you encounter Perm Gen memory errors then consider this or an even higher setting. See JVM options
    Any HTML editor will do. In Eclipse, associate .tml files with the HTML editor:

    Loom is a delight to use. It's an Eclipse plug-in that allows you to switch between a template and a java file by using a keyboard shortcut (Ctrl+Alt+X). To install it:

    Now open a page's .tml or .java file and try the keyboard shortcut.

    By default, the project automatically builds a WAR file for testing with Jetty. It's in a directory called collapsed/ and its format is "collapsed EAR", which is nice and simple. It's automatically kept up-to-date by a builder called collapser which you can see by displaying the project's properties and choosing Builders.

    To debug any part of JumpStart while running it in Eclipse (with RunJetty), use Run > Debug Configurations... instead of Run > Run Configurations.... Eclipse will then stop at breakpoints, display variables, enable single-stepping, etc.

    Source not found. At a breakpoint, Eclipse might display Source not found. Click Edit Source Lookup Path... > Add... > Java Project, select your jumpstart project and click OK, then OK again.

    Tapestry source. To read, step through, or debug Tapestry source you'll first need to download it from Tapestry 5 Download. Then unzip/untar/whatever it into your development directory, eg. /devel/tapestry-src-5.2.6.

    In Eclipse, choose File > Java Project, deselect Use default location, click Browse... and choose the Tapestry source folder. If Eclipse now complains that the project "overlaps the location of another project", re-select Use default location. Click Finish. The Tapestry source project will not compile, but that doesn't matter. Now you can find components and put breakpoints in them.

    As always at the first breakpoint, Eclipse might display Source not found. Click Edit Source Lookup Path... > Add... > Java Project, select the Tapestry source project and click OK, then OK again.

    By default, the project automatically builds a WAR file for testing with Jetty. It's in a directory called collapsed/ and its format is "collapsed EAR", which is nice and simple. It's automatically kept up-to-date by a builder called collapser which you can see by displaying the project's properties and choosing Builders.

    If you prefer, the project can automatically build an "exploded EAR" file which is readable by JBoss (and GlassFish?) and, for that matter, Jetty. It goes in a directory called "exploded/" and it can be automatically kept up-to-date by a builder called exploder which you can see by displaying the project's properties and choosing Builders. Just select exploder and, if you like, de-select collapser .

    Set collapsed and/or exploded directory to derived. In Eclipse, right-click on the collapsed or exploded directory, choose Properties, and tick the derived checkbox. Then click OK.

    To run the collapsed EAR in Jetty, follow the instructions on the installation page.

    To run the exploded EAR with JBoss, configure your JBoss server to scan the exploded/ directory, which you can do by editing the server's conf/bootstrap/profile.xml file to add the exploded/ directory to the "VFSDeploymentScanner" bean, eg.

    <!-- Scan for applications -->
    <bean name="VFSDeploymentScanner" class="org.jboss.system.server.profileservice.VFSDeploymentScannerImpl">
       <property name="profileService">
       <property name="filterInstance">
       <property name="URIList">
          <list elementClass="">
             <!-- Standard hot deployment directory -->

    JumpStart has a simple unit test suite in the business tier. Its name is BusinessUnitTestSuite. You can run it as a JUnit Test in Eclipse, or in Ant.

    Run with Ant

    Run as JUnit Test in Eclipse

    JumpStart's integration test suite checks that the business layer is operating correctly and that it is reporting all possible exceptions correctly. Its name is BusinessIntegrationTestSuite.

    Run as JUnit Test in Eclipse

    JumpStart session beans specify to use a persistence unit called jumpstart.
    The persistence.xml file maps jumpstart to 1 or 2 data sources. Their JNDI names are java:/JumpStartDS and java:/JumpStartDSUnmanaged.

    By default, OpenEJB overrides the data sources to its own which use the Hypersonic database in OpenEJB's data/hsqldb/ directory. This is handy.
    To override this behaviour, supply an openejb.xml configuration file. You can see this being done in other servers.

    For running in JBoss, the build script puts a configuration file called jumpstart-hsqldb-ds.xml in deploy/. The file maps the JNDI names to an HSQLDB database.

    Hypersonic provides a handy GUI tool for viewing the database and executing SQL requests, the HSQL Database Manager. To use it:

    To view and edit an HSQLDB that runs in JBoss, JBoss provides a handy way to open the HSQL Database Manager:

    Logging is configured by in business/src/dev/conf/.

    To log SQL statements, add Alternatively, to log everything Hibernate is doing, including SQL statements, schema export, transactions, etc., try For finer control of Hibernate logging, see the section on Logging here.

    You will also have to change the logging threshold of the CONSOLE appender from INFO to DEBUG. Alternatively, to avoid cluttering up the console log, create a new appender definition called, say, HIBERNATE, by copying one of the appender definitions called FILE (look for appender name="FILE"). Then define your new category like this: The new log will appear in the server's log/ directory when the first entry is written to it.

    The schema is defined by the classes containing the @Entity annotation. By default, JumpStart will automatically create/update the database schema to match. That includes creating tables and constraints when necessary. This behaviour is controlled by the property in persistence.xml.

    Unfortunately, you can't just override the behaviour at runtime eg. with some settings in a properties file in the conf/ directory. It seems that either Hibernate (or the EJB3 spec?) requires the Hibernate settings to be specified in persistence.xml, and the EJB3 spec requires persistence.xml to be inside the ear file. This seems like an oversight, but in fact is probably just right because it forces you to make your test environment match your production environment.

    Some changes don't seem to propagate to the database schema, for example switching a field from nullable=false to nullable=true. So at times you may decide to rebuild the schema.

    1. Backup the data This is optional, but the next step will delete all your data. The initial JumpStart data is re-loadable in step 4.
    2. Drop the tables Use JumpStart's drop_tables.sql script, or modify it to suit. If your database is JBoss's Hypersonic, use the HSQL Database Manager
    3. Create the tables Either run the ant target touch-exploded-ear in JumpStart's build.xml, or restart the server. See Altering the database schema above for details.
    4. Restore the data or re-load the initial data If you backed up the data in step 1, then you can restore it now. Alternatively, re-load the initial data with JumpStart's initial_data.sql script.

    To use MySQL with JumpStart, please upgrade to JumpStart 5.10.1 or later.

    To use database brands other than HSQLDB or Derby, please see the Tips for JumpStart 5.10.

    Choose a project name, root package name, etc., then edit the values in tools/ . Drag tools/tools.xml to the Ant view and run the target create-fresh-project. A new project will have been created with an Index page, Login page, the User and UserPassword entities and a few pages to maintain them. Then do much the same as you did from Step 2 onwards of Installation.

    The following links show how to prepare other servers and how to build, deploy and test JumpStart on them:

    GlassFish 3.1.1 support will be possible when JumpStart supports EJB 3.1 which will happen when Open EJB supports EJB 3.1.
    Tomcat 7.0 support may be possible when OpenEJB updates their Tomcat installer, openejb.war.
    JBoss 7.0 support has not been worked on yet.

    The package produced by a build is tailored to a particular server type, persistence provider, and database server type.
    So can a package be moved between servers? Yes, but only if they have the same...

    You tailor the build by editing the file. Here's what it affects:


    ©2006, 2007 Geoff Callender, Sydney, Australia