[jira] Resolved: (WW-635) Components and HttpSession persistence/distribution

["Don Brown (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/struts/browse/WW-635?page=all ]
     
Don Brown resolved WW-635:
--------------------------

    Fix Version:     (was: 2.0.0)
     Resolution: Won't Fix
      Assign To: Don Brown  (was: Patrick Lightbody)

The XWork IoC framework was deprecated in XWork 1.1 and will probably be removed completely in 2.0.  Still, if you find this a problem in other areas of Struts Action 2, please open a new ticket as this is an important problem.  Thanks.

> Components and HttpSession persistence/distribution
> ---------------------------------------------------
>
>          Key: WW-635
>          URL: http://issues.apache.org/struts/browse/WW-635
>      Project: Struts Action 2
>         Type: Bug

>   Components: Component Management
>     Versions: WW 2.1.1
>  Environment: JBoss 3.2.5/Tomcat5
>     Reporter: Rolf Arne Corneliussen
>     Assignee: Don Brown

>
> Short description:
> If using the IoC stuff of WebWork/XWork and a HttpSession is serialized, the Session scoped component manager is also serialized, and by implication also the application scoped manager is serialized. If the HttpSession is then deserialized in another JVM than it was created, it will bring with its own the application scoped manager, and not use the manager in its current application context.
> Elborated:
> The application scoped component manager is bound to a Servlet context, which have the following properties:
> * Its lifespan is linked to the web-application lifespan. limited by the JVM
> lifespan
> * It is associated with only one JVM
> * It is not supposed to be serialized
> The session component manager is bound to a HttpSession, which have a
> different set of properties:
> * Its lifespan is linked to the HttpSession lifespan, and HttpSessions can live longer than its hosting JVM
> * It can be transferred to another JVM after construction
> * It can be serialized
> The relationship between the application manager and the session manager is kind of *static*. The session component manager gets its parent application manager when it is created and is never changes after that. If the HttpSession it is bound to outlives the application or gets transferred to another JVM, it takes its application manager with it (because serialization follows the reference to its fallback app. manager).
> This leads to the following problems:
> * Our transferred session will have its own application manager that is different from the manager bound to its new servlet context
> * The application component manager has a different set of properties that does not include transfers between JVMs.
> The relationship could be handled more dynamically, so a
> session manager should drop the reference to its application component
> manager (that is, the fallback) when it is about to leave a JVM. When the session manager is recreated in another JVM, it should be connected to the application component manager that is the manager in its new JVM.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira