On Tue, 2002-07-23 at 15:15, Aleksei Valikov wrote: > Hi. Hi Aleksei!
> We've desided to move our system to Avalon neat! (and a wise decision...) > and I would like to ask for some > recommendations regarding serializable components. ah...tricky! > Our current problem is with serializable components. We do not want clients > to loose their data/application states during server restarts or > re-distribution of sessions. That is our single-threaded components,which > are stored in sessions were developed serializable. But how do we deal with > serialization from Avalon components lifecycle's point of view? just to make sure you considered this: you don't. You can implement activation/passivation outside the scope of the avalon lifecycle. You might want to read a recent thread on this on avalon-phoenix-dev [1] for more thoughts. How to Serialize/Deserialize components --------------------------------------- > But apart from creation and destruction, dessions may also > passivate/activate. For instance, a servlet container may move a session to > another VM to balance the load. Then, server restart. > During these phases, sessions are serialized and de-serialized, and > components will be serialized and de-serialized as well. just a 'terms' thing: I usually associate 'serialization' with data objects, and 'activation/passivation' with logic objects (potential components). > Composable, configurable and contextualizable components implement these > interfaces to get something from their containers/component managers/etc. > So, usually they store some references to objects. For instance, a > Composable usually stores either its componentManager > > ComponentManager componentManager; > > or a component that it requires from its component manager: > > MyComponent myComponent; > > If this composable component must be srializable, we're getting into a > problem. yup. > We cannot serialize componentManager or myComponent, because (1) it > is not clear, if they are serializable or not and (2) even if they are, > after de-serialization they will be cloned objects, not the original > manager/component (unless resolving is implemented). Consequently, > deserialization of complex (composable, context- or configuration-aware) > components is problematic. uhuh. > I failed to find component lifecycle stage, which would consider > serialization and de-serialization of components (if I missed, forgive me > and show me the way). there isn't any =) > The closest thing to that is suspending/resuming the > component: > > suspend() > recontextualize() > recompose() > reconfigure() > resume() yup. > I think that serializable components must answer following considerations: > > 1. References to external shared objects must be transient to avoid (1) > serialization problems (if external object is not serializable) and (2) > cloning after deserialization. > 2. If component implements basic lifecycle-oriented interfaces (Composable, > Configurable, etc), it must also implement correspongding re-interfaces > (Recomposable, Reconfigurable). > 3. If component needs to perform some actions before serialization/after > deserialization, it must be Suspendable. yup. > So, in my point of view, if the component must be srialized, the following > happens: > > 1. If the component is suspendable, it is suspended. Suspendable in this > case means that component need to do something before it becomes passive. > For instance, if a component stores DOM document (non-serializable), this > document is first serialized into a string (which is, of course, > serializable). > > After that component may be serialized (for instance, on server shutdown). > Now, let the server start again. > > 2. Container, which contained our components is somehow activated and > notified of the session activation. The components are de-serialized, but > they are in invalid state - their component managers and external component > fields are null (as they are transient). > > 3. Components are recontextualized. > > 4. Components are recomposed. > > 5. Components are reconfigured. > > 6. Components are resumed. > > After all these steps components are again valid. sounds workable. > The black hole here is logging. As there is no LogReenabled, parent > components could not set loggers in child components. The solution I see is > not to use LogEnabled - simply create logger in each of the components > explicitly. which is of course ugly =) It'be better to have LogReenabled (or ReLogEnable or whatever) in this setup. > This is my vision of component serialization. I must admit, I am an absolute > Avalon newbie, I downloaded ir last friday. I would be very grateful, if > someone more experienced in Avalon corrects me or gives an advise. If you really need serialization, it seems you've found the way forward on your own alrady =) There's a few gotchas: - we don't have a container that actually supports the Re* interfaces atm - you define a few new contracts above which are not guaranteed by avalon framework, thus you become dependent on a specific container implementation (which you'd likely have to create by extending an existing one, likely fortress) that does satisfy these contracts. Why you wouldn't want to ------------------------ It seems to me that what you really need is support for Session-enabled and Activation/Passivation of components. While serialization is one way to achieve both, I think it is not the easiest or the best. A Serializable object says "All the data I contain can be transformed into 'something' that can be sent over a network or stored in some way, and then that 'something' can be used to make an object which has the same type as me that has exactly the same data". Problem: *components* should not be about data, hence you should not (have to) implement Serializable. What we want to do ------------------ The idea of IoC [2] is that the container provides your components with its state, and that the component will behave the same when that state is the same. Thus, what you want to do is create a container that knows how to save and load state (where session information is just part of the complete state). In concrete terms, when your application needs to move to the new JVM, the container serializes state information for all components it contains to disk, then exits. When the application loads into the new JVM, the container reads this state information from disk and creates new components using it. This means it is not neccessary for your components to worry about saving their own state at all. We're not there yet ------------------- No avalon container supports sessions yet, though work is under way. Fortess [3] has experimental support for "extensible lifecycles", so this is likely the place where support for component sessions will first appear. While it should be not too difficult to support activation/passivation inside one of our avalon containers, none of them currently do. What I recommend you do ----------------------- If you're in a hurry, the quickest thing to do is probably one of a) not use avalon for the stateful parts of your application b) extend avalon fortress for your specific use case to provide specialized serialization support for your components where the best choice depends on how isolated the parts of your app that need to be serializable are. If your deadline is somewhere further along in the future, it'd be cool if you came over to avalon-dev to join the discussion on sessions and activation/passivation, and help out with the implementation of these features. This will get you the best solution =) Where to look for more information ---------------------------------- You should try the archives for avalon-dev and avalon-phoenix-dev (as this avalon-users list is quite new, the archive is still somewhat small) searching for terms like 'activation', 'passivation', 'serialize'. There's quite a bit IIRC. Or, come on over to avalon-dev and join the brainstorm sessions =) [1] - http://www.mail-archive.com/avalon-phoenix-dev%40jakarta.apache.org/msg00667.html [2] - http://jakarta.apache.org/avalon/excalibur/fortress/index.html [3] - http://jakarta.apache.org/avalon/framework/guide-patterns-ioc.html hope this helps ya a bit, regards, - Leo Simons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
