Sorry people, the trunk may be a bit unstable for some time. Why? Alejandro has started a furious effort of coding Trails 2.0 and merging in T5! In the meantime, I've been enjoying development with the superb ajax features of T4.x series (eventlisteners, async forms etc.) With that said, we had an interesting discussion on #trails over IRC, here's an excerpt (Alejandro aka billy):

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 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.