struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent SĂžlvsten Rasmussen <k...@aarhusmail.dk>
Subject Re: RE: why only one instance of Action class (Action class thread safety)
Date Tue, 06 May 2003 20:40:11 GMT
Instance variables (or properties) would be able to shorten parameterlists.

If Action had Request scope (implemented by instantiating new objects, or pooling), it would
be possible to let Request and Response be instancevariables or properties on the Action object
(populated by the framework). Thus they would be unneccessary in the execute method. This
could be a way (but possibly not the best!) to decrease the dependency of the Servlet API.
And maybe there could be a DefaultAction unaware of the Servlet API (easy to test), and a
WebAction with Request/Response properties, and maybe somewhere down the road a SwingAction?

This is, of course, very difficult to implement without breaking backwards compatibility.


Margaritis Jason Contractor USTC <jason.margaritis@hq.transcom.mil> wrote:
> Kinda new to struts,
> but wouldn't it be trivial to implement this on top of the
> current framework
> by having your Action instantiate a new Object (could be an
> Action) and go
> from
> there?  But i don't really see how instance variables are
> going to shorten
> parameter lists.
> 
> 
> -----Original Message-----
> From: Brendan.Johnston@WellsFargo.COM
> [mailto:Brendan.Johnston@WellsFargo.COM]
> Sent: Tuesday, May 06, 2003 1:35 PM
> To: struts-dev@jakarta.apache.org
> Subject: RE: why only one instance of Action class (Action
> class thread
> sa fety)
> 
> 
> I am still thinking about how to hack the Wiki but...
> 
> The advantages to the "action instance per request" approach
> are:
> 
> * The current approach means that users must be specifically
> cautioned about
> the issues for *actions*.
> * Instance variables can be used by both the framework and
> users to shorten
> parameter lists etc.
> 
> The disadvantage to this new alternative approach is that it
> is different
> from the current struts model.
> 
> If a mechanism can be invented so that new isolated actions
> are clearly
> distinguished from singleton actions to provide backward
> compatablity, for
> humans and source, then the change can be made.
> 
> I personally like instance variables, and I like not having
> to worry about
> shared variables when I don't have too.
> 
> Brendan
> 
> 
> 
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Monday, May 05, 2003 12:34 PM
> To: Struts Developers List; Bradley Hill
> Subject: Re: why only one instance of Action class (Action
> class thread
> safety)
> 
> 
> 
> 
> On Mon, 5 May 2003, Bradley Hill wrote:
> 
> > Date: Mon, 5 May 2003 10:59:26 -0600 (MDT)
> > From: Bradley Hill <alpn@gwl.com>
> > Reply-To: Struts Developers List
> <struts-dev@jakarta.apache.org>,
> >      Bradley Hill <alpn@gwl.com>
> > To: struts-dev@jakarta.apache.org
> > Subject: Re: why only one instance of Action class (Action
> class thread
> >     safety)
> >
> >
> > Indeed, the multi-threaded use of Actions is much like the
> Servlet API,
> > but most Struts users (not developers) at this point are
> probably more
> > familiar with the JSP APIs than with working directly with
> "pure"
> > Servlet apps.
> >
> 
> None of this is relevant for 1.x anyway, but I would counter
> this with the
> observation that people who don't understand the
> fundamentals of the APIs
> they are using are going to run into trouble no matter how
> "simple" we try
> to make them.
> 
> Case in point - sessions can be accessed from multiple
> threads
> simultaneously, and it's ridiculously easy to cause this to
> happen.  It
> doesn't matter whether you are used to the JSP or the
> Servlet APIs for
> accessing session attributes -- if you don't understand
> this, your app is
> going to fail in mysterious ways.
> 
> There are lots more similar issues that servlet and JSP
> inherit simply
> because they run on top of a stateless protocol (HTTP).  You
> cannot write
> robust web-based applications without understanding them --
> papering over
> the problems with simpler apis makes webapp development more
> approachable,
> but it cannot hide the fundamental ugliness of HTTP.
> 
> > Why not use the lifecycle model of a JSP tag for Actions? 
> Pool them for
> > performance (if it's even worth the trouble), include a
> reset/cleanup
> method to
> > be called by the framework, and guarantee single-threaded
> access within
> the
> > scope of a request.
> >
> 
> JSP 1.2 taught the world that the lifecycle model of custom
> tag instances
> was horribly hard to use, and even more difficult to program
> for than the
> thread-safe single instance model.
> 
> It is so bad that, in JSP 2.0, a new API (SimpleTag) was
> introduced that
> (among other things) dispenses with all the pooling
> complexity and just
> creates instances every time.
> 
> > It would be an equally familiar and easy to explain by
> analogy model for
> > most users and avoid the issues surrounding thread safety
> which, if in
> > practice are not actually so complicated, many find
> intimidating and
> > unintuitive.
> >
> 
> Strong advice from having lived through tags and pooling --
> don't go there
> :-).
> 
> > Brad Hill
> > bradley.hill@gwl.com
> >
> 
> Craig
> 
> ------------------------------------------------------------
> ---------
> To unsubscribe, e-mail:
> struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-dev-help@jakarta.apache.org
> 
> ------------------------------------------------------------
> ---------
> To unsubscribe, e-mail:
> struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message