Hi Berin, answer at the end... > -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 11, 2002 2:44 PM > > ... > > > I think it should be solely up to the work interface to release > the component > > if the component is actually just a shallow facade ontop of a > real resource. > > For instance close() when used on a JDBC connection would place > the real > > underlying resource back in pool. Similar methods will be used > with other > > resources/components but I don't think we should have a > Component interface > > provide such a method. > > > Ok. I was also thinking of how to provide a hint to the > Container that the > Component needed to be pooled. > > How do you propose that we address the issue of programatically > providing the > hint that a Component is pooled. Is this something we have to do with the > Manifest file? What is the proper method in your mind? > > > It is easy to deal with Components that implement a marker > interface when that > > interface has semantic meaning that is understood. That is why > the ThreadSafe > and SingleThreaded interfaces are currently useful. If we remove > the marker > interfaces, we have to replace them with some other method. > > The critical thing we have to address is whether a Component > should be unique > to each lookup, or whether the same instance can be used accross > all lookups. > Cocoon has proven unequivacably that pooling Components provides > a serious boost > in runtime performance and scalability. Furthermore, the cost of > synchronizing > access to critical sections of logic in a Component is cheaper > than pooling. > > That is why this lifestyle aspect is so important.
IMO you could have 2 ways of creating a component: 1) Generic factory; 2) Custom factory. In my experience 2) is enough and tends to produce components with more chances for reuse since you can usually place all framework dependencies (configuration included) in the factory and have components that can be used even without the framework. Besides, 2) does NOT produce much extra work. Actually, it helps my auto-configuration mechanism to work in such a way that the codes gets much shorter than in the traditional Avalon way. But you could still have 1) with markers. It is not a mutual exclusive option. With 1) the CM would always find the lifestyle of a component by asking its factory and the factory would know the component's lifecycle by checking what marker interfaces it implemented. What do you think about this option? Have fun, Paulo Gaspar http://www.krankikom.de http://www.ruhronline.de -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
