Blast from the past: Struts
Recently, I am working on a portal project at a bank and the framework that is used is Struts (version 1.x). Having used JSF for a few years now, I find Struts delightfully straightforward use and difficult to maintain. I got this portlet project dropped on my plate and find it difficult to find out where the data used by the JSPs comes from.
A typical Struts JSP gets the data from the request or session, which is just like a Map that can contains any arbitrary Java object (the session is supposed to hold only Serializable objects, although many programmers do not always follow this rule). This makes the request and session behave like a bag of global variables that get their contents set somewhere in some Action. You can track down request scoped attributes, since they can only be set by the immediate action, and since session scope attributes live as long as the session, almost any action that could have added it to the session. Also, these Action objects contain only one execute method, which promotes a procedural style of programming. Maybe this is why I sometimes see so many static methods in the project.
The use of a procedural style of programming and global variables makes it harder to maintain the code that I am working on and requires more big refactoring than I would like. I now find that a JSF application (done well) is much easier to understand than a Struts application. With JSF, you can look at a page and trace variables in the view back to configured backing beans and their properties.
Struts has served us well in all those years; we now know how to do things in a better way and let us move on to better frameworks...