David Pollak wrote a very detailed description of Scala SDK Actors on the Lift discussion list, some serious flaws are pointed out as a justification of why Lift has it's own Actor library:

• Lift creates/destroys an Actor for each Comet request. This rapid creation/destruction of Actors caused memory back-ups, and the existing Actor code seems to be oriented to long running Actors rather than Actors with Object-length lifespans.
• The FJ libraries used for Actor scheduling have problems on multi-core machines and are also a source of memory retention issues.
• Replacing the FJ libraries with a scheduler based on java.util.concurrent exposes race/deadlock conditions related to the fact that some parts of the Actor processing (e.g., testing mailbox items against partial functions while the Actor itself is synchronized)
• The Actors require external threads to function and it's not possible to create external threads in the Google App Engine (making Actor-based functionality including CometActors non-functioning in GAE apps)
• Actors are fragile when exceptions are thrown
• Actors have running and not running states (as compared with objects which can always respond to message sends). In practice, managing the running and not running states is as hard as managing memory in C.
• There are hidden actors associated with each thread which display the above fragility and state management issues
• And as a practical matter, I've got a couple of applications that are going into production over the next few weeks and cannot wait for the various fixes to make it into Scala 2.8 and the hacks and work-arounds that I've done to the 2.7.4 Actor libraries became too complex for my comfort.

Interesting to notice the authors worries about overcoming some limitations to run Lift on Google App Engine, what would certainly boost it's main adoption in a near future :)

The main goals of the WebWork Framework depicted on the Wikipedia's article:

1. Web Designer never has to touch Java code;
2. Create multiple "Web Skins" for a application;
3. Change Look and Feel;
4. Change Layout on a given Web Page;
5. Change Flow among Web Pages;
6. Move *existing* data elements from one page to another;
7. Integrate with various backend infrastructures;
8. Reuse components;
9. Perform internationalization (i18n) of a web application;
10. Keep the API small and to the point;
11. Ability to learn WebWork fast, by making all the fancier features optional;
12. Allow the developer to choose how to implement as much as possible, while providing default implementations that work well in most cases [1];

I'm not sure if the order on the list above reflects the priority but if so I would strongly use the items from 8 until 12 as the first top one priorities:

1. Reuse components;
2. Keep the API small and to the point;
3. Ability to learn <YOUR FRAMEWORK/API NAME HERE> fast, by making all the fancier features optional;
4. Allow the developer to choose how to implement as much as possible, while providing default implementations that work well in most cases [1];
5. Perform internationalization (i18n) of a web application;

An the last item is for certain one of the main strengths of the Springframework, as well as the terrific usage of Object Oriented advantages as Polymorphism.

I stumble upon this WebWork article because a tool I'm using for the past months makes some use of it :)

For those of you working or studying Java Workflow engines I've read this post on James Strachan's Weblog entitled POJO based Orchestration that might be interesting.

In the past I've had 2 bad experiences, one with Bossa, at that time o version 0.7 halted for a couple of years, navigating in its source me and a fellow coworker had the opportunity to see some odd code, which was a good show stopper.

The other bad experience what with JBPM that had been recently acquired by JBoss, but our main struggle was more with part of the team considering (me included) its use over engineering for that project needs. Even though one feature I can't forget was the use of beanshell statements inside the XML that represented our workflow, you can imagine the debug hell this strategy can emerge.