struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ranko Bijelonic" <>
Subject RE: Struts MVC framework similar to that of a servlet container?
Date Tue, 22 Jul 2003 08:55:11 GMT

First of all, I want to thank everyone for their responses.  I was concerned
that the questions I posed could be misinterpreted as an attack on Struts
and usefulness of the framework, and that I would get some heated responses.
However, everyone only tried to help me better understand the issues I was
struggling with.  Its a very nice and helpful mailing list here.

I agree that there should not be one solution for every possible need.  It
makes sense that standardizing on such a level would create an overly
confined environment.  So a framework such as Struts is built on top of the
servlet specification.  One issue that can come up in such a situation
though, is that the framework can somewhat isolate its users from the
changes and additions to the underlying specification.  These changes might
be useful, but since the framework was built on top of the older version of
the specification, using these changes does not come naturally in the
framework.  After enough of these changes have accumulated, it might be
helpful to rework that framework to make use of those additions, and to
expose them to the users of the framework.  That would probably result in an
improved framework that would fits better with the current state of the
specification it is built on top of. Of course I say this out of desire to
always use the latest stuff without having to worry about backward
compatibility and the huge user base :).  Some people have it easier than
others :).


-----Original Message-----
From: Craig R. McClanahan []
Sent: Tuesday, July 22, 2003 2:51 AM
To: Struts Users Mailing List;
Subject: RE: Struts MVC framework similar to that of a servlet

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
> 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:

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

View raw message