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 http://opensource.atlassian.com/projects/spring/browse/SWF-92 (note the mention of improvements coming in SWF 1.1). Regarding conversation support in Spring, these discussions are related: http://forum.springframework.org/showthread.php?t=37174, http://forum.springframework.org/showthread.php?t=32270 and http://forum.springframework.org/archive/index.php/t-41582.html. 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: http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/ , http://thoughtmining.blogspot.com/2007/03/grails-versus-rails-comparison.html and http://docs.codehaus.org/display/GRAILS/Grails+vs+Rails+Benchmark ). 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 http://tacos.sourceforge.net/tacos5/tacos-seam/index.html). 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 ) In the meantime, happy trailing!

Trolling with Java Web Frameworks by Fred Daoud

Brilliant, funny, certainly geeky.

I can't stop laughing!

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 Now, enjoy.

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 repo1.maven.org. 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 trails.dev.java.net site way higher than our current trailsframework.org, 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 http://trailsframework.org and make sure you change/remove the old links. Thanks