Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 54712 invoked from network); 18 Jan 2001 21:45:20 -0000 Received: from fw.infoplanning.net (HELO infoplanning.com) (@209.8.58.131) by h31.sny.collab.net with SMTP; 18 Jan 2001 21:45:20 -0000 Received: (qmail 26132 invoked from network); 18 Jan 2001 21:54:07 -0000 Received: from unknown (HELO apache.org) (192.168.0.189) by inet with SMTP; 18 Jan 2001 21:54:07 -0000 Message-ID: <3A67630A.9050508@apache.org> Date: Thu, 18 Jan 2001 16:41:30 -0500 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.7) Gecko/20010109 X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: instability of Cocoon from yesterday to now Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N I apologize for committing some code that caused Cocoon to be less stable. I was straitening out some incorrect assumptions that Paul had regarding the ComponentManager class (and I copied over to the ComponentSelector class). The issue was surrounding the assumption that there would only be one type of class per role/hint. The error was hidden from view until I made the ComponentManager and ComponentSelector configurable, and set themselves up. As I "fixed" errors, I created bugs and uncovered new ones. The current CVS should be stable now. Someone mentioned that they were having problems with the JdbcDataSourceComponent chewing up all the open connections and not releasing any. It came from this very problem, because the ComponentManager/Selector was creating new copies of ThreadSafe Components on every lookup/select. This is fixed now.