> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > > Furthermore, a GeneratorManager can declare its own > semantics. If you > > want the release() method there, then there are no issues > conflicting > > with overall CM design. > > Ok, it means that for Generator I should create > GeneratorManager, and for XXXXX - XXXXXManager.
Yep. > > > I think discussion here was carried away from topic... > Architecture > of > > > future Cocoon should be discussed separately. I was > trying only to > > > clarify how container will handle absence of the release() method. > > > > The GeneratorManager would handle the release() method, or it would > > declare its semantics for use. > > > > Component use should not be a function of component lookup. > > Ok. What then will be contract between component manager and > user? When you call lookup(), what should you expect - > Component, ComponentSelector, ComponentGenerator, Pool, > something else? > > Or, I always will get XXXXXManager? Then, lifecycle > management will be moved to XXXXXManager, right? You will always get the XXXXXManager. So yes, lifecycle does move to XXXXXManager. However, the XXXXXXManager can act as a container for older components--that way we don't have to throw away the work we already have done. > Good thing about ECM is that component writer can easily > switch ThreadSafe -> Poolable and vice versa without breaking > any code using his component. Will this be the case for new CM? It is a function of the Container--not the CM. The ECM mixes the concerns of a Container and a lookup mechanism. It is not optimal. Fortress is an example of a Container with a separate CM. It is even easier for the container or administrator to control the creation policy for components. It pulls that meta-info from a file. That way we don't run into strange things that happen in Inheritance hierarchies that would owtherwise confuse the ECM. > Also, I remembered about component factories (when component > is created on every request and destroyed on release). Will > this be supported with this new release()less design? You can > say that these single-use components are evil (as single-use > servlets), but this is the only choice for some legacy > applications/libaries. That control is moved to your XXXXXXXManager. It is not the CM's responsibility to manage your component instances--it is the container's responsibility. > > > > Yes, but you wouldn't necessarily have your production (i.e. web) > system > > doing this either. > > We have single J2EE container here for web and back-end... But if your expensive 8 hour routine was handled by a session bean or something similar (JMS bound session bean?), then the Servlet environment is not affected by the processing. See what I am saying? It is asynchronous to the web environment. > > > J2EE has REQUIRES_NEW transaction management attribute > for the EJB > > > method. If you have such methods (is it considered wrong design?), > all > > > required for this method TxResource-s should be looked > up, thus you > > > will have more then one instance of a component. > > > > J2EE also allowed you to declare Servlets as single use (not one > > instance per thread or sharing an instance among > threads)--does that > > make it correct design? It was a serious bottleneck allowing a Q&D > > hack. > > Sometimes you have to use some legacy systems, which are not > necessarily written up to high-end Avalon standards... > SingleThreaded servlets should be considered as a way to > integrate such things. You no longer have that option as of Servlet 2.3. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
