Trails 1.2.1 released!

Just like that, only half a year behind the schedule (practically nothing in open-source circles) we are releasing Trails 1.2.1! This version integrates with Tapestry 4.1.5 and will be the last major release based on T4. The release represent maturization of Trails codebase and hard work solely by Alejandro. The undersigned has mostly been enjoying the fruits of this work and meanwhile using the superb ajax-features of the matured T4 codebase, on top of a Trails-based application, how else. The release contains more changes under the covers than the release history shows, and for most Trails users should be a painless upgrade. Enjoy!

Trails 1.2.2 is still planned for the 1.x line, but waiting under the wings for the upcoming Tapestry 4.1.6 and a few other tricks Alejandro may have in his sleeve.

This is a partial re-posting of discussions on Trails dev list, to give everybody a re-cap on what's up with Trails. As most people following Trails know, Tapestry 5 has been a constant topic on our mailing lists and in 2.0 Trails will move to it! Since T5 is an entirely different beast from T4, it opens up a possibility for a whole slew of other changes. Another all-time favorite topic is session-per-conversation, one of the remaining "holy grails" of web applications. Despite the fact that session-per-request pattern doesn't provide any practical advantages over session-per-conversation (though you can argue about potentially lower memory usage), it's the prevalent implementation because implementing session-per-conversation in a generic way is just too difficult. To my understanding, JBoss' Seam is the first web application framework that really provides a generic support for session-per-conversation; not suprising considering Hibernate comes from the same people. Spring WebFlow comes close, the issue is tracked at (note the mention of improvements coming in SWF 1.1). Regarding conversation support in Spring, these discussions are related:, and Of course, there's been various other tries in implementing it, and session-per-conversation hass been used as a performance optimatization in custom cases, but a generic approach remains a challenge. For Tapestry, James Carman mentioned he was working on a long conversation support as part of his Tapernate module but I believe this effort stalled at some point. We later merged Tapernate into our codebase in order to be able to modify and bug fix it.

The issue with both Seam's and Spring WebFlow's approaches is that if you step out of the conversation, your conversation is "lost" and will remain open in the (servlet) session till it expires. Seam's default answer is it doesn't matter: they make the open sessions explicit in their sample applications with their workspace concept; basically reminding the user he had started but never finished these "tasks", and thus allowing the user to jump back in the middle of earlier abandoned conversation. This is a fine approach for enterprise web applications that are closer to desktop apps which require high amount of interaction but don't necessarily have a high number of users. In Trails, we are in a unique position compared to the other full-stack web frameworks like Rails and Grails, even Seam, because Tapestry has such a strong emphasis on high user-count, high-performant web applications. Not that I'm bashing either one; in contrary I applaud their efforts and innovations they've brought to the web application space. (And btw, there are interesting performance comparisons of the two at: , and ). It might be an interesting experiment to reproduce the tests in Trails, although they don't really focus on testing the view layer performance). Grails supports long conversations via Spring WebFlow integration. However, Trails simply is quite different from these frameworks in many ways and so I'm not convinced the somewhat xml-heavy WebFlow integration would be the right path for us.

Of course, nothing prevents one writing a semi-automatic workspace management layer on top of Seam that would take care of detecting and closing abandoned conversations. The Seam guys have carefully removed any dependencies to JSF. In practice, integrating Tap5 with Seam might be the fastest way of getting practical results for a conversational scope, and wouldn't solve only one but two problems at the same time (conversations and session-per-conversation), of course at the expense of tying the implementation more closely with Hibernate or at least JPA, but that's probably what the majority is using anyway. I'm sure the Seam guys would love to see Tapestry support for Seam. We are not alone in craving for Tapestry/Seam integration. Actually, such an integration already exists by Igor Drobiazko, a Tacos committer (see Unfortunately, at least the current integration doesn't address session-per-conversation, but simply the bijection of Seam components into a Tapestry application.

Given that Trails has traditionally been a full-stack web application framework and we've been good at using and integrating numerous other modules, we'll base off an initial version of Trails 2.0 on T5, Seam and tacos-seam integration. Even with current Trails, it's debateable whether Spring is needed, but it was always too late or too laborious to get rid of it. With a spanking new, built-in Tapestry IoC and Seam's bijected dependencies, Spring looks somewhat extra and at least initially we'll manage without it for Trails 2.0. The development will happen in a new branch, which we haven't even created yet.

Before we get heavily into Trails 2.0 development, we still have Trails 1.2 to clear out first. 1.2 will be the last major Trails release from T4 line. Most major stuff have been implemented, but we are still waiting on T4.1.4 release and then sorting out the remaining bugs. It's likely that some of the less important ones will be moved out for possible future bug-fix releases. After 1.2, we'll be steaming ahead with Trails 2.0. (The Tapestry/Seam explains the word play with Steam, but I'm sure we can produce a bit more than just hot air (wink) ) In the meantime, happy trailing!

Trolling with Java Web Frameworks by Fred Daoud
Brilliant, funny, certainly geeky.
I can't stop laughing!

Trails 1.1.1 released!

Just three days after releasing 1.1, we are releasing 1.1.1. And no, we didn't have a major screw-up or suddenly find some odd bugs in the codebase, but nevertheless we had two issues. One of them was that the archetypes were referring to snapshots versions and the other one a issue with one of the latest check-ins which went unnoticed through two unit tests particular to the issue and some amount of manual testing. Well what can I say, these things happen. We could have bumped up the version numbers of only the affected modules, but since that would have required more manual changes than just rolling out a new point release, we took the sure - and more automated - way. Most of the code is 100% the same as in 1.1, so we'll treat 1.1.1 as our official 1.1 release and just chalk up the earlier release as a fire drill (smile) Now, enjoy.

Trails 1.1 released!

Right on schedule, we are releasing Trails 1.1! It feels it's been so long, even though it was less than six months ago we hit 1.0. I almost keep forgetting because I've been using 1.1 for months, but the single biggest difference between 1.0 and 1.1 is the modularized architecture. The documentation gives you an overview of the new modules, but the important thing about it is that it allows Trails to be used in more heterogenous use cases, independent of whether your project is using Hibernate or Acegi. Definitely cool stuff. As usual, Alejandro has done a lot of the heavy lifting in the modularization and various other areas. One of the other more visible changes he made is the new default user interface and layout that's designed to be compatible with AppFuse so users of that project should feel right at home trying out our examples. One more super-exciting feature he worked on is our first draft of full-text search based on Trails-Compass integration that we have a whole section about in the User Guide. The release history gives you a brief overview of the major features and a summary of the 30 bugs that were fixed in this release.

While the initial plan for 1.1 was to integrate with Tapestry 4.1.2, 4.1.3 contained important bug fixes for us and since it was released just recently, we decided to go with it for 1.1. Earlier unannounced and technically not part of the release, we've also quietly merged our Confluence-based site with a custom Maven site style, transparently blending Maven site reports with the Codehaus project wiki. For example and to see what other dependencies we've upgraded, check out the dependency report. Just as when I'm writing this, I can see Trails 1.1 is already available in Enjoy and let us know how we can improve!

Let's see, what did I say in the last post? That "we get the improvements to the presentation layer for free". In the next point release of Trails, version 1.1, we've focused on upgrading the framework to use Tapestry 4.1.2. While the Tapestry core itself is great and stable, the new byte-code compilation enhanced OGNL has taken some time to mature. It's slowed us down a bit but once again, Alejandro has done a lot of ground work to make the upgrade happen and Jesse Kuhnert has been great at fixing emerging OGNL bugs. A lot can be said about Tapestry 4.x' learning curve but I doubt many would seriously challenge its position as one of the leading and most comprehensive Java web application frameworks at the moment. On top of it, Tap 4.1.2 introduces built-in integration with Dojo. In 1.1 we won't rely heavily on AJAX functionality, but we'll demonstrate some parts of it and we have great plans for it in future versions.

Not to make this post a praise on Tapestry, there's also a few other main features we wanted to introduce in 1.1. We are tracking those fairly closely on our simple roadmap and at this point the feature work for all of them is already done. One feature highlight is the security enhancements that provide a real, rigid security for Trails application out of the box - compared to the earlier light approach that was simply based on hiding the information from the view alone. Personally, I've grown to hate the "hello world" examples that demonstrate how super-easy it is to develop something simple with that new next-generation web application framework of choice, but then stop short of providing anything for those more complex, but equally critical real-world problems like providing security. We decided to tackle the issue by providing something for the typical scenarios, and so, as a result in Trails 1.1 a use case where a user can edit his profile (and ONLY his own profile) can be secured with just a single annotation. Not bad, huh? And of course, it's implemented with extensibility in mind. We call the concept "owner instance" -based security, where the currently logged in user is required to have some relationship with the entity he wants to view or modify. Are there any other Java web application frameworks that do the same out of the box?

The remaining items before we we are ready for a release involve collapsing the development branch to the main trunk, adding some test cases and then revising the documentation. Our informal estimates have been holding up surprisingly well so far so we are hoping to get the release out sometime this Fall for all of you Trailers!

PS. While I have no ambitions to make Trails the most popular Java web application framework ever, I'm a bit frustrated that Google still ranks the old site way higher than our current, even though we switched over a year ago and Trails has matured quite a bit since the early days. Linking to old material might be confusing for newcomers that are looking for a better way to implement web applications. What you can do, is to link to and make sure you change/remove the old links. Thanks (smile)

At JavaOne this year, there was a presentation on "Grails, Trails and Sails - Rails Through a Coffee Filter". There's been a few comments on it scattered in various blog posts (at least and, so it seems fitting to have some reply to it here. As mentioned in the blogs, I had the honor of announcing that I had just weekend before JavaOne tagged Trails 1.0 release.

Overall, I thought Trails faired well against the competition, and while the presenter used several months old version of Trails, he made a decent job demonstrating it. Only Sails doesn't seem like an active project, so mainly it was a comparison of Trails to Grails. The presenter mentioned that Grails is semantically closest to Rails and it's picking up steam compared to others, and that he's not sure if Trails is addressing enough pain-points. Certainly, even the whole Tapestry community is small compared to Struts or JSF, which already has an effect on the number of people interested in Trails or those who've even heard about it. But I'd have to disagree with the latter statement about pain-points. I've always thought that besides helping you to start quickly with your project (which all of these Rails-like projects do), the greatest strength of Trails is that it combines all of these state-of-the art frameworks into one and leverages their strenghts rather than introducing yet another way of doing things, such as the custom presentation layer in Grails. Tapestry has already solved some hard problems, like concurrency issues, caching the templates and re-using presentation objects, which allows us to focus on cases that none of the current web frameworks support: instance-based security, web flows, long conversations and modularizing the framework in order to have built-in support for different persistence layers etc. Currently, Trails uses Tapestry 4.0.2, but we are committed to moving to Tapestry 4.1.2 in Trails 1.1, and when new versions come out, we get the improvements to the presentation layer "for free".

Whenever these comparisons happen, there's always the question whether the separate projects could leverage each others or even merge. It's said many a times that it probably wouldn't have been possible to implement Trails-like framework without Tapestry, and so Trails is dependent on it. There's no way nor need for Trails to change to something else, and therefore couldn't merge with any other project. Similarly, Grails is married with Groovy - the project undoubtedly wouldn't exist without it. Groovy is cool though, and you could technically write Trails/Tapestry code with it, but it wouldn't help any when writing the Tapestry code templates - arguably the hardest but most powerful part of Tapestry. And that's final advantage of Trails: it is a remarkably flat framework, there are no additional layers obscuring you from customizing the application with the techniques available in each framework. So, if you are versed with Tapestry, Spring and Hibernate, it's almost a no-brainer to use Trails for a new web application.

Trails 1.0 released!

After a year of development, with lots of changes in the team and project hosts, moving to Maven as our build system, re-writing most of the docs and fixing a number of bugs, we have finally made Trails 1.0 release! Follow the Quick Start guide to get started!

Brian Sam-Bodden did a session about Trails in CodeMash last January. He has blogged about it in Integrallis's blog .
His presentation is available for download at Integrallis site under "publications" , look for "RAD with Trails".

Archimedes Trajano tells us why he chooses Trails in his blog:

Site Hosting at Codehaus

Over the past few weeks, you may have noticed things changing. The site has been moving to a new home at The Codehaus, and quite a bit has gone on as a part of that move. Here's a short list of what's been done so far:

  • Site Content
    Over time, the information for Trails has become spread out over several different sites, including, and a few others.  This lack of a central document repository makes it difficult to get started with Trails.  New users need to be aware of these different locations for things, and bounce around to collect the different information.  As we bring that information together under the banner, there will be a single source for all information about Trails.
  • Source Repository
    Codehaus provides excellent tools for managing developers and their contributions to Subversion through Xircles.
  • FishEye
    If you haven't seen FishEye, you owe yourself a look.  Being able to subscribe to source repository changes with your RSS reader is a treat!
  • Continuous Integration Server provides Continuous Integration services, and Trails is set up with Continuum.  Over time, we expect Continuum to notify developers over IRC and mail when build failures occur, providing a higher level of usability for the source tree trunk.
  • yDoc JavaDoc
    Codehaus projects are licensed for yDoc, which generates navigable UML diagrams directly into the project JavaDoc.  Over time, we expect Continuum to keep this updated automatically.  The JavaDocs tell the entire story.
  • IRC
    Some folks have started to congregate at irc://  Please feel free to join us!

And here are some things that still need to be done:

  • Maven Repository
    Very shortly, we should have the Trails artifacts available at  This will allow everyone to get trails without adding an explicit repository reference to their POM!
  • Mailing Lists
    Bob is working on getting the mail import finished.  He's using RoR, so it's taking a long time (wink) Seriously, we're really excited to get the lists moved over so we can start to take advantage of the great tools in Xircles for list management.  As a part of this, we would like to find someone who has an archive of many or all of the messages from the past.  If you have ideas, please contact Brian Topping.
  • JavaDoc Content
    In an effort to make it easier to get involved with Trails, a push is being made to get the project documented.  At the same time, some members are simultaneously bringing the code up to the JDK1.5 level and refactoring it for better readability.  If you would like to participate, documentation is a great way for new contributors to come on board, in large part because new people see unfamiliar code with great vision for how to explain it.  Please post to the dev list if you are interested.
  • Jira Move
    While Confluence has been moved and is being used to generate the site, Jira is still waiting to be moved.  Please take a moment to participate by voting for this issue to be resolved in Jira!
  • Site Redesign
    It would be really great if someone with the HTML skills to redesign the site were available to help us make our site look great
    Interested in helping?  Please ask!
Trails .9 released

I hadn't realized quite how long it's been since we did a release (November!). I think this one has been worth the wait though. It includes some major new features:

And some less major ones:

  • Refactoring of search
  • Bookmarkable links
  • Override blocks for table columns

Some things have changed a bit as well and are worth pointing out:

  • Several files (applicationContext.xml, hibernate*) moved from WEB-INF to the classpath. These live in a conf directory and are copied by the build process.
  • The Hibernate annotations have been updated to 3.1beta8.  There is a change to the annotations for generated ids.  Existing code will need to change to use the newer annotations.  See Hibernate annotations docs for details.

And as always, there's lots I'm forgetting I'm sure.

New Features

From James Carman:

Today, I checked in some code with the following changes.

  1. "Friendly" URLs
  2. Hibernate connection settings can be overridden in the file for trails projects. This way, you don't have to edit the file.
  3. Removed some of the "deprecated" components (Conditional) and properties (selected vs. value for a Checkbox).
  4. Now using Spring autoproxying rather than having to specify the proxy/target for persistenceService. All methods marked as @Transactional will cause Spring to create a proxy around your bean for the transaction interceptor.
  5. The hivemodule.xml file has been moved from src/META-INF/hivemodule.xml to base_app/WEB-INF/hivemodule.xml. I did this because if an end user wants to disable friendly URLs, they have to change the hivemodule.xml file and that's kind of tough to do when it's inside trails.jar in the lib directory.
  6. The SqueezableSqueezeAdaptor has been implemented and plugged in. Unfortunately, we don't have any DirectLinks that use entities as parameters, so I couldn't really see how well it worked.

Note: These changes are in Subversion only.

Spring MVC Version of Trails

From Lars Vonk:

We have created a first version of Trails with Spring MVC as view
layer. It can be found in this branch:

It is not as mature as the Tapestry version, but the basic
functionality should be in there. Running ant create-project from the
root creates a Trails project the same as the Tapestry version. Please
feel free to test it and give some comments (yes i know we need more
unit tests...) on this Trails variant.


Logo Contest

Trails is looking for a logo. If you have any good ideas, upload them to the Logo Contest page.