struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: Struts MVC framework similar to that of a servlet container?
Date Tue, 22 Jul 2003 06:50:57 GMT

On Tue, 22 Jul 2003, Andrew Hill wrote:

> <snip>
> all this great filters in place of ActionServlet direction
> </snip>
> I could be wrong about that, thats just the impression I get from the posts
> and discussions here and on the dev list. It seems a logical conclusion
> though.

Herein lies one of the realities of standards-based development --
standards never evolve as quickly as some people would like.  For others,
though, standard evolve far too quickly and eliminate the opportunity to

For better or for worse, Struts 1.x is going to remain based on Servlet
2.2 and JSP 1.1 as the base technologies, for as long as people listen to
me (I *hope* that will be for a while yet :-).  You see, the other side of
developing a widely adopted technology (even if it's only a "de facto"
standard instead of an "official" standard) is that it's totally
unreasonable to abandon your users and customers who have committed
substantial effort and expense to building applications based on that
platform.  If we (the Struts developers) were to say "sorry, folks, but
1.1 is the end of the line for software that will run on your J2EE 1.2
server", they would have a very justifiable reason to abandon Struts.  But
that's not going to happen.

Ranko, Struts came into existence in the first place to provide a single
solution to a series of problems that a very large number of people have
had -- how do I architect a large scale web application so that the cost
of maintenence doesn't kill me?  Indeed, one of the most common comments
on the Struts mailing lists in the early days was "I was just building
something like this ... I'm delighted that I can adopt a common standard
so that I can focus on building software for *my* application, instead of
reinventing standard infrastructure."

The servlet API did not then, and does not now, provide all the
capabilities needed to meet all of those needs in a "Java standard" way.
As I described in my earlier message, though, the right answer is *not* to
extend the Servlet API to do this -- instead, it is to create standardized
frameworks for all of the relevant use cases, on *top* of Servlet.  There
is more than one need.  There is no such thing as *any* single framwork
that is going to be able to meet all of them.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message