Related conversation. - Sam Ruby ---------------------- Forwarded by Sam Ruby/Raleigh/IBM on 02/26/2001 11:57 AM --------------------------- Giacomo Pati <[EMAIL PROTECTED]> on 02/26/2001 11:55:41 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: AW: [C2]: Component Pooling and recycling Carsten Ziegeler wrote: > > Berin Loritsch [mailto:[EMAIL PROTECTED]] wrote: > > > > Carsten Ziegeler wrote: > > > > * Paul Russell wrote > > > > > > > > * Carsten Ziegeler ([EMAIL PROTECTED]) wrote : > > > > > > * Carsten Ziegeler ([EMAIL PROTECTED]) wrote : > > > > > > > I would suggest to change the behaviour of 3. and 4. that > > > > Recyclable > > > > > > > > > sitemap components are always recycled and that Poolable > > > > > > > sitemap components are alyways returned to the pool - > > > > > > > regardless if they declare PoolClient or not. > > > > > > > > > > > > How do you propose doing the last? > > > > > > > > > > The ResourcePipeline currently gets the sitemap components > > > > out of the > > > > > > pool > > > > > > > > > and puts them back if they declare PoolClient. I would add at that > > > > point > > > > > > > an additional test for Poolable and Recyclable. The > > > > > > > > SitemapComponentSelector > > > > > > > > > must be extended by a put-method() for this. > > > > > > > > Uhuh. Might make more sense to add the 'put' method to the > > > > CocoonComponentSelector, which is where all the pooling code seems to > > > > be. > > > > > > Ohh, yes the CocoonComponentSelector is the one. > > > > > > > Other than that, I have no major problem with it. I still think the > > > > Avalon ComponentManager interface needs changing so that it contains > > > > a 'put' method, however. Anything that can 'compose' a component > > > > should > > > > be > > > > > > able to 'put' it back afterwards. Everything we're doing to get > > > > around this looks like a hack to me. > > > > > > Yes, exactly. This hacking is the reason why I am asking first - I > > > > thought that I perhaps had overlooked something. > > > > > So I think, we should do the hack first and then when a corrected > > > > ComponentManager is available we can remove it. > > > > That was my thinking when I created the PoolClient interface. I would > > really like the ComponentManager/Selector interfaces to remain "pure". > > Especially since that is the way they are cast in the whole of Cocoon. > > Your proposed solution will cause us to be required to cast as > > CocoonComponentSelector--which is not a guarantee. We should lobby > > Avalon for the change to the official interface--and use PoolClient > > in the mean time. > > Ok then, this means using PoolClient instead of Poolable everywhere and > everything works fine. > > What about the Recyclable components? Is it correct, that a Recyclable > component can be used without Poolable (or PoolClient) ? If so, who is > responsible for calling recycle() ? IIRC the Recyclable interface extends Poolable. Giacomo (still 194 mail to read from this list :) > > Carsten > > > C > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
