Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 11307 invoked by uid 500); 5 Jul 2002 10:57:59 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 11288 invoked from network); 5 Jul 2002 10:57:59 -0000 From: "Leo Sutic" To: "'Avalon Developers List'" Cc: "Cocoon Developer's List" Subject: RE: [BIG PROBLEM]: Order of component initialization Date: Fri, 5 Jul 2002 12:58:25 +0200 Message-ID: <000601c22412$e40131d0$0801a8c0@Lagrange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-OriginalArrivalTime: 05 Jul 2002 10:57:58.0827 (UTC) FILETIME=[D3072FB0:01C22412] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Dependency in ECM works like this, I believe: If A looks up B and B isn't yet initialized, B will be initialized. So you can do this (for now): Subclass the connection, if possible, and put some code in its compose() method that will lookup the database component. That should force the initialization order. I agree that this is ugly and all, but it should solve the problem if you can not get ECM to work properly. You can always hack ECM to get the behavior you want, but that might be more difficult. (Depends on whether you are under time pressure or not). /LS > -----Original Message----- > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de] > Sent: den 4 juli 2002 16:22 > To: Avalon Development > Subject: [BIG PROBLEM]: Order of component initialization > > > Hi, > > in Cocoonland we have a simple problem which prevents > us currently from releasing the new version :( > > The problem is the order of initialization of components or > to be more precise the initialization of the DefaultHandler > resp the DefaultComponentFactory. > > We have the following scenario: a database component which is > Startable and a database connection refering to the database. > > Now in the Cocoon xconf where all components are defined is > the database located before the database connection, but > unfortunately the connection is initialized before the > datbase which makes the connection unusable. > > The problem is the BucketMap, the ExcaliburComponentManager > uses to store the handlers. The handlers are entered into the > bucket map in the order they appear in the xconf, but during > initialization a Set is used to fetch these handlers and then > they are processed more or less in an arbitrary order which > is not controllable at all. They great think about this, is > that the order is currently JDK dependant as the used Set > seems to be implemented different in 1.3 and 1.4. > > Now, does anyone see a good solution for this in Excalibur? > I think a logical implementation would be to initialize the > components in the order they are configured. > > If there is no solution in Excalibur we must see what we can > do in Cocoon, but currently I see no good solution there. And > a dependecy between components might be a common thing. > > Regards > Carsten > > > -- > To unsubscribe, e-mail: > unsubscribe@jakarta.apache.org> > For > additional commands, > e-mail: > > --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org