Hi, Leo. Thanks for the letter, Leo. :)
> > We've desided to move our system to Avalon > > neat! (and a wise decision...) Actually, we found out that the system we were developing has too many common points with Avalon. We have developed a web application framework, where the system is composed of a number of components. The idea is that in order to build a new web application, the user specified, which component he would like to use in this system and their configuration as well (very close to ExcaliburComponentManager stuff here). I'll describe the system a little bit. I don't want to be boring, but it seems to me we did something you haven't done in Avalon. Current implementation is based on servlet technology. The servlet creates an Application component, provides it with configuration, context, logger, etc. There is only one instance of Application component pro web application. Provided with configuration, the Application component loads all the classes specified in the configuration. Thread-safe classes are instantiated immediately. The Application component has a DefaultComponentManager for them. Thus, thread-safe class instances will be shared among the clients. Non-thread-safe classes are not instantiated. They are saved in Class[] componentClasses array (there are also several functions to access this array/its length etc). There is also a class called Model. It is a container for single-threaded class instances. Each client (each new session) requires its own Model. Model instances are created from Application. Being Composable, Model can access Application, correspondingly, array of single-threaded classes of this Application. In such a way, the Model creates instances of single-threaded classes. Each Model has its own DefaultComponentManager, created on Application's component manager basis. The Model performs lifecycle of its sub-components. Effectively this creates one Application component per application (containing instances of thread-safe components) and one Model per session (containing instances of single-threaded components). Due to hierarchy of component managers, single-threaded components have access to other single-threaded components of this session and thread-safe components. Finally, each session has a Model with access to all configured set of components. Our previous development, Model-Transformers technology allows mapping HTTP request parameters on method calls of the model for model instruction and model presentation with XSL transformations. This is applied to receive web-ready application composed of several components and XSL transformations. If you think this could be contributed to an Avalon sub-project, we're ready to discuss this. > > 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 =) Ok, I'm not too bad at searching, then. > > 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. How wrong would it be to simply use LogEnabled once again? This will sound something like "If you use this container and your LogEnabled component has Serializable marker, enableLogging(...) will be called once again to provide a new logger right after de-serialization and before recontextualize(...) call". That would be fine for our components, but I'm not sure about it in general. Alternatively, LogReenabled is of course ok, but a little bit ugly. :) > 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. Now I understand - this is clearly my design fault. I've checked the documentation once again. The misuse is that our components also store data. There is, for instance, document editor, which stores document that the user edits. That is, our components are stateful. What are the recommendations to deal with data? > 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. I've checked Fortress... Perhaps I have to read more about it, but it does not seem directly applicable. Maybe I have to reconsider it, but I don't think that these lifecycles may be exteded the way I want them to. > 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 We're not in that hurry, I don't feel like giving Avalon up only because serialization implementation was not that straightforward. With b) maybe it makes sense, but I would first prefer to implement serialization in a suitable way and only then consider Fortress. I've already written the containers, so there will not be deliverables for us in Fortress-based implementation other that implementation is Fortress-base. Maybe it makes sense in long-term (Fortress-compatibility, etc), but currently its an overhead. Currently I've solved the serialization issue by calling enableLogging in Model.resume() once again. For a temporary solution it's ok, I only have to check if it's ok with Avalon concepts. > 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 =) Well, this sounds interesting, thank you for the invitation. :) I only have to repeat - I've started with Avalon last Friday and I don't feel very confident about all the Avalon concepts. I'll do the following: I'll clean up few things in sources and show them in avalon-dev. If someone from dev-people helps me making the solution along with Avalon concepts, this may become a contribution. > Or, come on over to avalon-dev and join the brainstorm sessions =) I'll do. :) I don't think my brain makes that much electricity, though. :) > hope this helps ya a bit, Ja, thanks, Leo. :) 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]>
