On Tue, 2002-07-23 at 18:19, Aleksei Valikov wrote: > Hi, Leo. > > Thanks for the letter, Leo. :)
no prob =) I'll just throw in some more components. > > > 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. avalon's been a loooooooooooong time in the making....we did lots of different stuff....half of which I know nothing about.... > 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. it sounds like your Applicaton component is the container. > 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). one thing avalon does is decouple from Class. part of our mantra: - use interfaces. They're bliss - use roles. Interface has connotations and limitations (inheritance's a bitch at times) > 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. it sounds like what you call 'single-threaded' is in effect components where you share classes, not instances. With avalonized software, you usually share instances of components (or a pool of them if they're not threadsafe). > 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. similar to the various web app frameworks here at jakarta =) > 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. sounds interesting. > If you think this could be contributed to an Avalon sub-project, we're ready > to discuss this. discussion is always nice =) However, if your code has much todo with web application frameworks (ie servlet stuff), you'll notice we have quite of those around here at apache. The uniquely valuable pieces (as opposed to the duplicated) might make more sense moving into the turbine project (which is moving towards using avalon). > > > 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. if you talk about sharing class definitions, there is no problem whatsoever! If you share instances, by avalon contract the container should not call enableLogging() more than once during the lifetime of the component. So you should create a new instance on which you call enableLogging. > > 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? Separate, then encapsulate. This is a general design pattern; you could take a look at Swing, or at monarch [1] for more information. Also, check the links on Design Patterns on the Avalon framework website [2]. > > 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. I'm not saying give up, just that if it is too much pain to refactor, don't manage your stateful components (like the document editor) using an avalon container but using your hown grown solutions (which already work), where you put your 'subcontainer' (ie probably what you call Model) inside an avalon container. > 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. it sounds to me like (and I haven't seen your code so this is a huge assumption) like the value for you is that you will be forced to do some refactoring that will result in a cleaner applications (with all the advantages like speed, stability, etc). ie the general COP framework advantage... > 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. it's not, of course, but if it works.... =) > > 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. it takes about a week for really smart people I believe...took me longer than that =) > 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. sounds cool! A single word of warning: the actually published and released parts of avalon and the contracts that go with them (ie you call enableLogging() right after <init> (ie constructor), and only then) are set in stone (for stability and compatibility reasons, but also because they usually make a lot of sense). [1] - http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/krysalis/krysalis-monarch/ cheers, - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
