> From: Leo Simons [mailto:[EMAIL PROTECTED]] > > Basically, you need to be able to store a component State > (session is a misnomer, I think). In avalon framework, a > component State *should* be defined by > Configuration+Parameters+Context+ComponentManager+Lifecycle > stage, even though this is probably not the case for many > components as this is not enforced.
<snip/> Not what I was talking about. I am referring to a component in its fully active phase. It can be used by different clients. However, if the component communication requires a certain order on calling methods, then we should store enough information with the client (i.e. session information) to be able to do its work. One example is the Generator component. While I think it should be rethought, I can't do anything about it right now. We do something along these lines: generator.setup(...); generator.setContentHandler(...); generator.execute(); The setup(...) would bind the necessary information (like the input stream for the SAX events or request parameters, whatever) to the session object. The setContentHandler() would bind the contenthandler to the session. that way, if the component is reassigned because other resolving is taking too long, we can safely resume where we left off. The information is no longer stored in the component, but in the session object. When the execute() is done, the session is cleared or invalidated. That is the purpose I was envisioning. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
