Just upgraded to Seam 2.2.  The initial impression is very positive, with a few old gripes tossed in.

Ajax

I use a mix of ajax4jsf and Seam Remoting for my apps.  I have a pretty good handle on the internals of A4J, and I’d guess there are at most 5 people in the world who know more about Remoting than I do (except for maybe the concurrency with A4J.  See below), so I have sort of a feel for Seam and Ajax.

Right off the bat, A4J performance is significantly increased.  The pages come up quick and there’s not as much churning going on.  With Firebug on, it was pretty obvious that the size of data downloaded, and the number of downloads, was significantly smaller.  I had been starting to look around for another Ajax toolkit, as I felt that A4J was too sluggish for serious sites.  The jury is still out somewhat, but its MUCH better now.

The more subtle issue that I’ll be playing with is concurrent requests to a long-running conversation.  Conversations are Seam’s way of handling state in a web application.  They’re like “super sessions”.  I can’t really explain it better than that, but maybe this can.  I haven’t worked with another framework in a while, so I’m not sure I’d know how to build a web application without a similar conversation model.  However, one thing we found out pretty quickly is that you can’t have two requests hit the conversation at the same time.  This happens quite a bit if you’re doing a lot of Ajax calls.

Preventing that with either A4J or Remoting, on its own, was pretty simple.  Just force them to serialize their calls.  However, if a remoting call and an A4J call went at the same time, Blamo.  Same issue if you had a standard page command button or link that was called while either of the Ajax processors were working.  Kablooe.

There is a way to serialize those calls, described in the seam docs.  Looking at the 2.0 seam docs for the same feature, and from general experience, I don’t think Remoting was involved with the same timeout.  That, or we were just not aware of it.  In any case, I think you’d want to bump that number up from 500.  While that’s an eternity in web time, still, in almost any case where the conversational call fails, you’d wish you’d bumped it up.

So, anyway, assuming the concurrent-request-timeout works as advertised, there’s a lot of paranoid code that I have to go back and strip out to make the whole thing simpler.  For example, I changed the navigation to use A4J buttons, because other parts of the page used A4J, and I needed a simple way to serialize everything.  Now, not so much.

That will probably wait for a month or two, as it may cause unanticipated issues.  However, glad its there.

Great job Seam people.

The gripe was the build differences and merging them into my build customizations.  Not sure how this would be done, but there should be a way to extend the build without requiring a full merge and debug on every upgrade.  It wasn’t pretty.  Without some good tools available, it wouldn’t have happened.

I dig the groovy support.  I vote for adding liquibase into the package.

Happy Holidays.