Currently, the new URLRewriting support uses a single method on the set of rewrite rules called "process".
This method is called both for transforming incoming request urls and for rewriting "outbound" links. Generally, however, urls from incoming requests are going to be translated into tapestry-aware urls and urls for links will be mapped from tapestry-aware urls to some external form. To facilitate the "in" vs. "out" mapping, URL Rewriting should provide a mechanism to distinguish between rewriting incoming urls vs. rewriting links.
Three possible ways of doing that are:
1) have a separate service for incoming vs. outgoing rewriting
2) Alter the URLRewriterRule API to change from the single "process" method to two methods: "processIncoming" and "processOutgoing" (or something along those lines)
3) Alter URLRewriterRule API to pass an additional "RewriteContext" method parameter. The context would include (for now) a single method "boolean isIncoming" or perhaps "boolean isOutgoing". (Alternatively, we could change the method signature to just provide a boolean "isOutgoing" parameter; but providing the RewriteContext would allow the API to evolve better in the future should we find that additional context information is useful).
Currently leaning towards #2. The positive point in #3 could be handled in the future by the introduction of a per-thread "helper" service, RewriteContext or some such, that could be injected directly into the rewrite rules.