URL rewriting

Tapestry URL Rewriting Support


Starting with Tapestry 5.2, the URLRewriterRule service has been replaced with the new LinkTransformer service. This page needs to be revised to reflect the new API. Meanwhile, please see Igor Drobiazko's excellent blog post on this topic.

Since, Tapestry has basic support for URL rewriting. Incoming requests and links generated by Tapestry can be rewritten using exactly the same API, based on a chain of URLRewriterRule interfaces. These rules are executed before all other Tapestry request handling, so your application does not otherwise know that the received request is not the original one.

Each URL rewriter rule, in its Request process, can choose between returning another Request, effectively rewriting it, or returning the received request unchanged, meaning that this rule does not apply to that request.

To facilitate Request creation, Tapestry provides the SimpleRequestWrapper class. It wraps a Request, delegating all methods except getPath() and getServerName(). More request wrappers may be added in the future on demand.


Tapestry's URL rewriting support is configured by Tapestry-IoC through contribution of a URLRewriterRule to the URLRewriter service. The following example is part of the Tapestry's tests.

Simple example of rule chaining

This example just rewrites all incoming requests to /struts to /tapestry. In your AppModule or any other Tapestry-IoC module class:

Example of rule chaining

In your AppModule or any other Tapestry-IoC module class.

This examples shows the URL rewriting chaining: the first rule rewrites requests to /struts and rewrites them to /jsf and leaves requests to other URLs unchanged. The second rewrites /jsf to /tapestry and the third rewrites /tapestry to /urlrewritesuccess.

The result is that any request to /struts end up being handled by the same class that handles /urlrewritesuccess, while the browser, the user and Tapestry still sees /struts.

Note that this applies to rewriting links generated by Tapestry too: a PageLink to the urlrewritesuccess page with an activation context of login (path /urlrewritesuccess/login) will generate an a tag pointing to http://login.domain.com.

The URLRewriteContext (added in provides additional information for rewriting, particularly in the context of rewriting generated link urls. In the following example, we'll reconfigure the url used to render pages. Whereas the previous examples used separate rules for handling inbound and outbound rewriting, this demonstration will utilize a single rule for both scenarios. To simplify the example, we will assume that every page is named "XXXPage" (UserPage, TransactionPage, IndexPage, etc.). This naming convention also means that we don't have to worry about tapestry's auto-stripping of "index" from URLs, because our page would be IndexPage, rather than Index.

In the first part of process, context.isIncoming() determines if the call to process occurred due to an inbound request. If so, the rule reverses the mapping done in the second portion of the method, so tapestry sees the original request.

The second half of process rewrites only page links by retrieving the logical page name and replacing its occurrence in the url with the shortened form of the link. This code segment demonstrates how the additional information provided by URLRewriteContext can be used to rewrite urls in a generalized manner.

Note that getPageParameters() will only return non-null when process is called due to page link creation, and getComponentEventParameters() will only return non-null when process is called as a result of creating component event links.