My History of Struts 2

by Don Brown

Since arriving on the scene in 2000, Apache Struts has enjoyed a very successful run, by most any standard, helping to build many, if not most, of the Java-based web applications deployed today. Its history tells of how Struts provided a solid framework to organize the mess of JSP and Servlets to make developing applications, which used mostly server-generated HTML with a touch Javascript for client-side validation, easier to develop and maintain. As time moved forward, and customer demands of web applications grew and grew, Struts 1 pretty much stayed the same, leaving more and more plumbing to the web developer.

At JavaOne 2005, several of the Struts developers (Martin Cooper, Don Brown) sat down with Rich Feit (Apache Beehive) and a few Struts users to discuss the future of Struts. We came up with the Struts Ti proposal, which described a framework that brought together a lot of good things that were developing in the web framework community. The problem is that the Struts 1 code base didn't lend itself to drastic improvements, and its feature set was rather limited, particularly lacking in features such as Ajax, rapid development, and extensibility.

At the same JavaOne, I sat down with Jason Carreira of the OpenSymphony WebWork 2 project to discuss how we could better work together. I was interested in building on XWork, the core of their command pattern implementation, but he suggested building on WebWork 2 directly. As Rich and I worked on the first few versions of Struts Ti, we decided to take Jason's advice. We thought it was time for a framework to address higher level application needs, and by building on the proven WebWork 2 framework, we could spend our precious spare time where we felt it would make a difference. From then on, Rich and I worked mostly with Patrick Lightbody, also a core WebWork 2 developer, and found ourselves constantly "stealing" each others ideas for our respective code bases.

Around this time, Patrick and Keith Donald of the Spring WebFlow project were kicking around an idea of a web framework to bind them all, Clarity. Clarity brought together Spring WebFlow (Keith), Struts (Ted Husted and myself), WebWork (Patrick and Jason), and Beehive (Rich) to talk about the possibility of combining efforts into one framework. Unfortunately, the devil is in the details as soon as Beehive and WebFlow were unable to make progress on merging their wizard/conversion scope features, and questions about project ownership, brand, and identity soon broke up the party.


Wille Faler
2006-10-25 02:32:51
So if I am getting this right, anyone familiar with Webwork2 should be able to get familiar (or even migrate) to Struts2 relatively quickly?

Does Struts2 come with any Ajax MVC type functionality, being able to invoke an action and re-render only part of a page?
So far, I have used my own little rolled up thing consisting of generic Javascript, Xwork/Webwork and DWR glued together, but it wouldn't be bad to use something a bit more widely spread. :)

Don Brown
2006-10-25 10:38:20
Yes, in the Struts 2.0.x release series, we are trying to keep migration for WebWork 2 applications as simple as possible. Migration is a top priority not only for the project, but for me personally, as I'll likely be moving my day job's app, Confluence, to Struts 2 from WebWork 2.

As for server-side support for Ajax, currently, we are keeping with the WebWork 2 strategy of supporting DWR and Dojo. I'd love to look into tighter integration, so if you have any ideas, please post them to our dev mailing list and start the discussion.

Don Brown
2006-10-25 10:52:08
I should also point out we have a migration guide for Struts 1 and WebWork 2 developers:
Wille Faler
2006-10-25 16:03:37
Just signed up to, and posted some ideas to the dev-list (with a link to some code I made at the beginning of the year).

Hopefully the ideas may be useful. If not, I'll probably be enlightened as to how the scenario already has been solved within Struts2. :)

Corby Page
2006-10-26 06:57:19
This is one of the great stories (up there with the AspectWerkz/AspectJ merger) of open source developers setting aside competing interests to make the world a better place.

I'm sorry to hear that the Spring guys wouldn't play ball. Spring MVC is the weak spot in their portfolio, and it would have been really great for them to roll in along with Webwork.

2006-10-26 09:33:41
Great article..really makes things simple in order to understand what happend! I Agree that the period of struts / shale subproject - project were much confusing! Well done again..keep us updated about the whole process...
Ted Husted
2006-10-29 05:12:39
> Clarity brought together

Was not Clarity a gang of three: Don, Keith, and Patrick? The projects were kept in the loop, but, as I remember, Clarity was set up as an "expert group" with one representative each.

> Patrick casually suggested the idea of a merger,

Hmmm, just as Clarity was winding down, Kito Mann spontaneously created the Weg Alignment Group. Kito was not aware of the Clarity discussions, but the WAG had the same general goal: a convergence of frameworks.

Unlike Clarity, WAG was open to all members of open source Java Web application frameworks. It was during posts to the WAG forum that Patrick mentioned the notion of WebWork "joining forces" with another framework. The four of us had a brief offlist discussion (archived here: that created the initial proposal.

> At JavaOne 2005,

And prior to that, in April 2004, at a conference in NYC in Jason Carreira and Ted Husted discussed the idea of using XWork under Struts, instead of our custom action mapper. Ted and Don continued that discussion over Guiness at ApacheCon 2004. At that time, Beehive, which uses Stuts 1 as a foundation, was being incubated, and convergence was in the air. :)

2006-12-07 03:21:52
I'm Ann,
from Sri Lanka,
and I'm 20 y.o

Hi, Everyone
I've studied English sinse this Winter .
It's so hard Language!
I would like like to meet girls and practisice My English with them.

2006-12-15 22:17:00
CAn Any one please help me iwth some articles on Struts 2+ ajax
2007-01-10 16:31:41
Good to see it's a happy family. But I also agree with this perspective:

Diwakar Ranganathan
2007-02-09 04:34:33
good article about the struts2. it helped me a bit introduction about this new big version... keep us updated.
2007-02-09 04:35:14
nice article
2007-03-16 09:48:06
Struts 2 is realy going to hit the market
2007-03-16 09:49:24

2007-04-11 11:07:02

For that kind of feature I successfully used AjaxAnywhere(SF) I don't know if Struts2 will use a similar approach or not...
Check the listings and not only in the photo site linked under my name.

2007-06-30 10:24:43
I was playing with Ruby on Rails in the last couple days, and I was surprise how easy/nice everything was package together. The little tool Instant Rails puts Apache, MySQL, Rails (MVC+OR) all in 60MB. Let's put performance, tools, IDE and all other debates aside, why can't we do something like that? A simple package that has Tomcat+Hibernate+Struts2 and MySQL all together. And a little script that look into the db schema and automatically spits out webpages for simple CRUD on each table.

I know the CRUD app is not going to do much, but for a beginner who wants to build a website, this gets him running on the right frameworks in minutes and he can start playing with the code. As for now, server side Java just has too many layers and frameworks out there that confuse the hell out of beginners. Choices are good, but only when I know how to choose and what to look for. After that, there is another hurdle of gluing them together. Even for an experienced developer like myself who played with Hibernate & Struts 1 couple years back, it took me a whole afternoon to get a skeleton well-manner web app up and running.

When my little cousin who wants to learn programming asked me where to start, I told him head for the Rails. For me, I am too lazy to learn another language & framework (well I need to pick up Struts2 now). I am staying with Java and hope I can finish my little facebook app within couple weeks...

2007-11-13 20:11:54
tutorial de struts 2
2007-12-31 17:27:18
Hello Don, I read your blog posts regular and it's always excellent reading.
2008-01-28 05:14:45
could you please send some sample programs on Struts2
Jonathan Revusky
2008-03-19 09:46:48
"The problem is that the Struts 1 code base didn’t lend itself to drastic improvements, and its feature set was rather limited, particularly lacking in features such as Ajax, rapid development, and extensibility."

I take issue with the above. There are two reasons why. The first is that it is patently false. I will elaborate on the second reason further down.

In my experience, even code that is not very well designed can be refactored forward. I do not believe that such work could not be done on Struts 1. The reason the project stagnated technically, as far as I can see, is simply that the maintainers of the project did not do the work. Not only did they not do the work, they did not bring in any collaborators with the gumption to do the work.

In any case, it is easy to find concrete proof that a lot of new ideas could be brought into Struts 1. Just as one example, look at the Strecks project or read an interview with the creator at .

Now for the other reason that I take exception to your statement that Struts stagnated technically because the codebase simply did not lend itself well to doing anything with it....

In early 2006, I ended up in something of a heated discussion on the struts list about this very topic. It began when I entered a discussion about the criteria for making people committers. I suggested that you could drastically lower the bar for letting people commit code and the sky would not fall in. This was in a context where I was well aware of the lack of technical progress in Struts. And surely the others involved in the conversation were aware of this. The answer I got to the points I raised was basically: "We have the 'Apache Way' and that says you do things like so." I then asked a perfectly natural question: "If this 'Apache Way' is such a great way to run an OS project, and you (presumably) followed the Apache Way, how come the thing stagnated so?"

The responses I got were fascinating. I got flamed a lot, of course. Ted Husted OTOH simply pretended (I'm pretty sure he was pretending) to misunderstand the question. He answered as if I had asked him what the Apache Way was and pointed me to the relevant scriptures on it. Of course that wasn't my question. My question was why the project stagnated if your practices were so good, actually, like Caesar's wife, above suspicion.

This led to me finally restate the topic of the thread as "Why did Struts stagnate?" This was a direct question that Ted and others could not deliberately misunderstand (via the willful obtuseness game.) As best I can remember, none of the principal people in the Struts community even attempted to answer the question. Rather pathetically, Craig McClanahan granted that it was a valid question but that he would not answer it because I was such a reprehensible individual. As best I can determine, his judgment of why I was such an undeserving person (undeserving of an answer) was that I had posed this very taboo question.

My point is that if the reason that Struts stagnated was that the code simply did not lend itself to further improvement, surely you or somebody else would have simply answered the question that way. Nobody did. My sense of things is that this explanation is something that you have just invented more or less out of thin air and it's not to be taken seriously. The project stagnated because the insiders didn't do the necessary work, and also it was a poorly run project that could not attract any motivated person from outside to do the work. This is what somebody with any common sense would think.

Now, a question you might pose is why I think this is important.

Well, you're writing a "history" of this so-called merger. (I say so-called because it's not much of a 'merger' since technically speaking the Struts side had nothing to offer, so Struts 2 essentially is Webwork..) But obviously, the point of the history is to invite appraisal (preferably positive, I guess) of this whole process that occurred. As such, I think the quality of management and processes in Struts prior to the merger is a very important thing to consider. You seem to be saying that progress stagnated, not because the project was badly run, but mysteriously, it simply wasn't susceptible to improvement (despite the existence of third-party extensions like Strecks that obviously do improve on the thing.) OTOH, if, as I believe, the project stagnated because of the poor culture of the Struts community, this should cause great misgivings about such a 'merger'. In a sensibly structured world, a cutting edge project should not be taken over by one that failed to progress and became obsolete. The managers of the obsolete project should not be imposing their culture and processes on the community that did the superior work.

Darwin's theory of evolution is, after all, based on survival of the fittest, not survival of the lamest or survival of the laziest. When such a merger occurs (it's not too frequent fortunately) in which the managers of an abjectly inferior project take over a technically superior one and impose their culture and way of doing things (which had such dismal results) on the successful project, does this operate in the interests of the broader community? Obviously the creator of Strecks harbored similar doubts when he said in the above-linked interview:

"I'm not convinced, however, that the change they did eventually go for - adopting the WebWork code base - was either necessary or in the interests of the Struts or WebWork user communities as a whole."

So I think I am not alone in my views. I think this is a valid viewpoint that should be presented for people to ponder.

2008-04-18 03:02:49
Can any one send me the code for implementing dispatch action in struts 2
2008-04-28 07:45:56
Nice work by Mr Brown, Thank You Sir!

Vajahat Ali Niazi
Softinn, Lahore