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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
