On Thu, 26 Aug 2004 11:01:33 -0500, Joe Germuska <[EMAIL PROTECTED]> wrote: > Action classes are pooled, not created anew for each request. > Therefore, use of instance variables runs a risk of synchronization > problems, in much the same way as does the use of instance variables > in servlets. > > It seems as though there's not a whole lot of gain from pooling > Action classes, but that's how it is now. After a discussion at the > Wisconsin Software Symposium in the spring, I felt that we had > several good reasons for changing Struts to instantiate a new action > for each request instead, but I can no longer recall what they were! > Personally I doubt that the performance overhead would be that great, > but perhaps there should be a better reason for changing it, > especially since there would necessarily be some more overhead for > repeated action creation. >
There were two original motivations for the current design of Actions: * Emulate the way that servlets work, to be familiar to existing Java web developers. * To minimize per-request object creation overhead, which was a much more serious issue in earlier JVMs than it is today. The primary motivation to consider changing the design would be to *allow* people to use instance variables in their action classes for per-request state information. While there could be some legitimate concern that this will encourage "incorrect" behavior (embedded business logic in actions instead of delegating to business objects), it also avoids the need to explicitly pass object references around inside the action. One particularly clever approach to the "action per request" paradigm is the way that WebWork does it -- they combine what we call ActionForm and Action into a single class, so their "form bean" processing is simply calling setters on the Action instance that will ultimately process the request. Then, when you call the action method, you don't really need to pass the servlet API objects -- all the incoming data that is relevant has already been provided (essentially, using setter injection in IoC terms). You'll see exactly this pattern used in JSF applications too ... the JSF framework's "managed beans" capability can create the "action" bean for you on demand, and the value binding expressions will do the updating for you; so you don't even need a framework for that part of what Struts can do. A side advantage is that you can typically use POJOs for your action classes, making them quite a lot easier to unit test. Craig > Joe > > > At 11:09 AM -0400 8/26/04, Zhang, Larry \(L.\) wrote: > >Can some one tell me why the above is correct? Thanks. > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn > back; I'll know I'm in the wrong place." > - Carlos Santana --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
