struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
Subject Re: RE: why only one instance of Action class (Action class thread safety)
Date Tue, 06 May 2003 21:52:14 GMT
Why should we reduce dependency on the Servlet API?  Servlets are the Java 
standard web application technology.  Struts is a web tier MVC framework 
enabling fast application development.

David

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

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail


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