Live Class and Template Reloading

One of the great features of Tapestry 5 is automatic reloading of changed classes and templates. Page and component classes will automatically reload when changed. Likewise, changes to component templates and other related resources will also be picked up immediately. In addition, starting in version 5.2, your service classes will also be reloaded automatically after changes (if you're using Tapestry IoC).

...

• org.example.myapp.pages
• org.example.myapp.components
• org.example.myapp.mixins
• org.example.myapp.base
• org.example.myapp.services (Tapestry 5.2 and later, with restrictions)

File System Only

Reloading of classes and other files applies only to files that are actually on the file system, and not files obtained from JAR files. This is perfect during development, where the files in question are in your local workspace. In a deployed application, you are somewhat subject to the implementation of your servlet container or application server.

...

For example, your service may be in the business of creating new classes based on component classes, and keep a cache of those classes:

public class MyServiceImpl implements MyService, InvalidationEventListener
{
  public final Map<String,Class> cache = new ConcurrentHashMap<String,Class>();

  . . .

  public void objectWasInvalidated() { cache.clear(); }
}

...

In your module, you will want to use a service builder method, such as:

public static MyService buildMyService(@Autobuild MyServiceImpl service, @ComponentClasses InvalidationEventHub hub)
{
  hub.addInvalidationListener(service);

  return service;
}

...

Starting with Tapestry 5.3, Live Class Reloading only works when not in "Production Mode". Check your application module (usually AppModule.java) to be sure you have:

configuration.add(SymbolConstants.PRODUCTION_MODE, "false");

...

• Be sure your project source files (your workspace in Eclipse, for example), are on a local drive, NOT a network location. Network drives are always slower, and the file system scanning needed for LCR can add a noticable lag if I/O is slow. If you use Maven, be sure to put your local repository (e.g. ~/.m2/repository) on a local drive for similar reasons.
• Since LCR adds classes to your PermGen space, you may be running low on PermGen memory (and may eventually get a "java.lang.OutOfMemoryError: PermGen space" error). Try increasing PermGen size with a JVM argument of something like -XX:MaxPermSize=400m

{scrollbar}