Tapestry docs, issues, wikis & blogs:

Release Notes 5.2

Release Notes 5.1 Release Notes Release Notes 5.3

This is the consolidated list of changes between Tapestry versions 5.1 and 5.2. To upgrade from 5.1 to 5.2, most users will be able to just update the Maven dependency in their POM file (or download the new JAR file) and the new version will just work. However, please read carefully below before upgrading, and also review the How to Upgrade instructions.

Contents

Breaking Changes

The following changes have been made in Tapestry 5.2 that are likely to result in unexpected behavior if your application relies on the changed functionality. Please review this list carefully before upgrading from 5.1 to 5.2. Also check the Deprecated API List for non-breaking changes.

Previously valid code in 5.1.0.5:

<t:form><t:label for="search"/><t:textfield t:id="search" size="50"/></t:form>

Combined with JavaScript that references the id:

jQuery('#search-label').text('This is the search label');

New JavaScript code for 5.2:

jQuery('label[for=search]').text('This is the search label');

Release Notes: Tapestry 5.2.6

Tapestry 5.2.6 is a maintenance release.

Bug

Improvement

Release Notes: Tapestry 5.2.5

Version 5.2.5 is a maintenance release for 5.2.4.

Bug

Improvement

Release Notes: Tapestry 5.2.4

Version 5.2.4 replaces version 5.2.3, which had an incorrect version number in the quickstart archetype.

Improvements

Release Notes: Tapestry 5.2.3

Bugs Fixed

Improvements

Release Notes: Tapestry 5.2.2

It is now possible to generate an absolute URL from a Link object; an absolute URL includes the URL scheme, host, port number (if necessary) followed by the complete path. This is useful in a number of situations, such as when generating a URL that may be e-mailed to an end user.

The semantics of the Link.toAbsoluteURL() method has changed; in prior releases it returned a complete URL (i.e., starting with a leading slash), and the method was typically used when generating an Ajax callback URL. Starting in 5.2.2 this generates an absolute URL (as described above). In most cases, you should change code that invoked toAbsoluteURL() with a call to toURL() instead; because Tapestry no longer 'optimizes' URLs, this will work for Ajax cases as well.

Deployed Tapestry applications often run behind a firewall, the available Request information about incoming hostname and port is often not accurate (it represents the private request from the firewall server to the application server, whereas the client uses a public request to the firewall server). When using absolute URLs, you will likely want to override the BaseURLSource service to provide accurate values that reflect your application's deployment.

Bugs Fixed

Improvements

New Features

Tasks Completed

Release Notes: Tapestry 5.2.1

Prior releases of Tapestry attempted to "optimize" URLs, by creating relative URLs where appropriate. Unfortunately, that caused its own problems with Ajax requests, since the base URL for an Ajax request is not the same as the base URL for the enclosing page. In any case, this feature has been removed, all URLs are now complete URLs (they start with a leading slash, and include the context path and the additional path that describes the page, page activation context, etc.).

As part of this change, the internal RequestPathOptimizer service has been removed.

Bugs Fixed

Improvements

New Features

Tasks Completed

Release Notes: Tapestry 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

New Features

Tasks Completed

Release Notes 5.1 Release Notes Release Notes 5.3