Release Notes 5.2.0

Tapestry 5.2.0 represents nearly a year of work past the prior stable release, 5.1.0.5. For the most part, the upgrade is quite straight forward, but please read the notes below carefully.

Live Service Reloading

Tapestry 5.2.0 extends Tapestry's concept of live reloading of Java code into the service layer. In most cases, service implementations of your application will now live reload, seamlessly. See the FAQ for some additional notes about live reloading.

Pages No Longer Pooled

This is a huge change from Tapestry 5.1 to 5.2; Tapestry no longer pools page instances. It creates one instance of each page (per supported locale). Tapestry rewrites your component classes so that all mutable state is stored in a per-thread HashMap. This will greatly reduce Tapestry's memory footprint, especially on heavily loaded sites.

This change makes it easier to share objects between threads, which is problematic when the objects are not thread-safe. For example:

Valid Component Code (5.1)
  @Inject
  private Locale locale;

  private final DateFormat format = DateFormat.getDateInstance(DateFormat.MEDIUM, locale);

  public String getCurrentTimeFormatted()
  {
    return format.format(new Date());
  }

In the above code, under 5.1, the DateFormat object was not shared between threads, as each thread would operate with a different instance of the containing page. Under 5.2, the final field will be shared across threads, which is problematic as DateFormat is not thread safe. The code should be rewritten as:

Updated for 5.2
  @Inject
  private Locale locale;

  public String getCurrentTimeFormatted()
  {
    DateFormat format = DateFormat.getDateInstance(DateFormat.MEDIUM, locale);
tapestry.page-pool-enabled
    return format.format(new Date());
  }

If such issues are difficult to solve, remember that as a temporary work-around you have the option of re-enabling the page pooling behavior of 5.1 by setting tapestry.page-pool-enabled to "true" in your configuration.

Service Id Injection

In prior releases of Tapestry, a constructor parameter of type String was assumed to be the service id. In the many cases where these was not the case (such as using the @Value or @Symbol annotation), the parameter needed to be annotated with the @Inject annotation.

Starting in 5.2.0, this feature is no longer present (this is a non-backwards compatible change, but one that affects virtually nobody). A parameter of type String will be subject to normal injection; you will likely want to use @Value or @Symbol with it, or you will see an error that "No service implements java.lang.String.".

Igor made a change such that a bare String is injected as the service id in some circumstance; it may be decorator methods. This needs to be documented properly.

TranslatorSource

The configuration type for TranslatorSource has changed in an incompatible way: from an unordered collection to a mapped collection; this is to support overrides of Tapestry's
built-in translators. This will break existing module classes that contribute to the TranslatorSource service configuration.

Assets

There have been some changes to how assets operate in Tapestry 5.2.

Virtual folders, used to define root packages for component libraries, may no longer contain slashes. Virtual folders are the pathPrefix property of the LibraryMapping objects that are contributed to the ComponentClassResolver service.

Each LibraryMapping is now automatically converted into a matching contribution to the ClasspathAssetAliasManager service. Previously a library author was encouraged to make contributions to both services. The path prefix of a LibraryMapping is also now prohibited from containing the slash character.

It is now quite necessary to configure the application version number: all assets are exposed via a URL that incorporates the application version number; in previous releases, each library could configure its own version number. By implication, changing library versions and nothing else will now require a change to the application version number.

ClassTransformation API changes

The ClassTransformation API, used to implement component meta-programming, has been rewritten with an eye to making class transformations easier to implement while removing the dependency on the Javassist library. This is of note only to advanced users who have implemented ComponentClassTransformWorkers, which operate on the ClassTransformation API.

Much of the existing API has been deprecated and some deprecated methods are now non-functional. The deprecated methods will be removed in Tapestry 5.3.

This represents a shift in how the API operates; previously much of the logic in ComponentClassTransformWorkers was built in terms of Javassist: adding new bytecode to existing methods. The new API switches away from this, and now works in terms of adding new fields, initializing those fields using callbacks, providing callbacks for access to fields, and adding advice to methods.

Template Parser back to SAX

Tapestry no longer uses a StAX parser to parse component templates, it has reverted to using a normal SAX parser. This change reduces the number of dependencies for Tapestry, and is a stepping stone towards compatibility with Google App Engine.

Bugs Fixed

Improvements Made

New Features

Tasks Completed