struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 30428] - RequestProcessor should bind form beans after population, not before
Date Mon, 02 Aug 2004 16:05:00 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30428>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30428

RequestProcessor should bind form beans after population, not before

craig.mcclanahan@sun.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From craig.mcclanahan@sun.com  2004-08-02 16:04 -------
Changing this would create problematic backwards incompatibilities, but there's
a more important issue.  The situation is not *exactly* as you describe.

Section SRV.7.2.2 says "Within an application marked distributable, all requests
that are part of a session must be handled by one Java Virtual Machine (JVM) at
a time."  In other words, the container is only allowed to migrate a session in
between requests, not during a request -- so there is no problem on the request
that actually creates the session-scoped form bean in the first place.  Even
though the bind happens before the population, that request is still in progress
and cannot be migrated until after the request is complete (when the properties
will have been populated).

What happens on the second request to that session scoped bean?  Exactly the
same thing ... the processActionForm() method will cause an existing form bean
to get rebound if it is in session scope.  Again, the ordering of binding versus
population does not matter (unless your servlet container isn't smart enough to
remember which session attributes were bound/rebound during the request and grab
the data at the end, in order to ensure it's copying the most recent data),
because by the end of the request the form bean *will* have been updated.

That all being said, people who are building distributed applications should be
focusing on minimizing the amount of state saved in session scope, and so should
be using request scope form beans.  Indeed, so should nearly everyone writing a
non-distributable application too.

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


Mime
View raw message