Hi. We've desided to move our system to Avalon and I would like to ask for some recommendations regarding serializable components.
We'have developed a web application, in which user manipulates certain component on the server side. Components are really different - data source, XML document editor, language pack and so on. Each of the components is now refactored according to the Avalon specifications. The application is written in a very flexible way. Similarly to ExcaliburComponentManager, the administrator configures, which components will be used in application. These components are either ThreadSafe or not (no pool support currently). The application is implemented as a servlet, each client has its own thread, its own session. Correspondingly, thread-safe components (language packs, document schema models, etc.) are shared between clients, while other components are instantiated for every new session and then saved in this session. A special controller component receives request from the servlet (we have specified a special RequestAware contract for that) and maps HTTP request parameters onto methods of other components (literally, invokes their methods). 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? The initialization stage is quite clear. Single-threaded components are created and initialized, when a new session appears. This lifecycle stage is fully ok. Destruction phase is also fine: it's possible to notice session destruction and invoke stop() on Startable and dispose() on Disposable. 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. 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. 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. 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). The closest thing to that is suspending/resuming the component: suspend() recontextualize() recompose() reconfigure() resume() 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. 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. 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. 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. Thank you in advance. Dipl.-Inform. Alexei Valikov e-mail : [EMAIL PROTECTED] Forschungszentrum Informatik (FZI) Telefon : (+49) 721 9654 716 Haid-und-Neu-Str. 10-14 Fax : (+49) 721 9654 709 76131 Karlsruhe GERMANY -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
