Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 74056 invoked from network); 25 Apr 2002 02:49:13 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 25 Apr 2002 02:49:13 -0000 Received: (qmail 5649 invoked by uid 97); 25 Apr 2002 02:49:19 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 5633 invoked by uid 97); 25 Apr 2002 02:49:19 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 5622 invoked from network); 25 Apr 2002 02:49:19 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Peter Donald To: "Ant Developers List" Subject: Re: cvs commit: jakarta-ant-myrmidon/container/src/java/org/apache/myrmidon/interfaces/executor ExecutionFrame.java Date: Thu, 25 Apr 2002 12:46:52 +1000 X-Mailer: KMail [version 1.4] References: <20020423072105.9970.qmail@icarus.apache.org> <200204251156.37283.peter@apache.org> <200204251230.53364.adammurdoch@apache.org> In-Reply-To: <200204251230.53364.adammurdoch@apache.org> X-Wisdom: A right is not what someone gives you; it's what no one can take from you. MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200204251246.52406.peter@apache.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Thu, 25 Apr 2002 12:30, Adam Murdoch wrote: > > yep. But now we start to get into territory that is a bit icky. We wi= ll > > end up creating a fully fledged services kernel if we are not careful= =2E > > The above strategy was one the Cocoon project used to use until they > > realized that some services/components were accessing other component= s > > before those other components were fully initialized. (The same thing > > happened in Avalon/Phoenix kernel). I believe they ended up creating = a > > directed graph for dependencies between services and so forth which s= eems > > like a little overkill for Ant - what do you think? > > Definitely overkill. I think we can get pretty close to what we need b= y > doing what DefaultEmbeddor does: create all the services, add them to t= he > service manager, and only then start moving them through the lifecycle > stages. Perhaps if we were to also move all the services through a > lifecycle stage, before moving to the next stage, might be useful. The problem with this is that it is going to break in some systems. If yo= u=20 write a service that accesses other services in any of the lifecycle meth= ods=20 then there is a chance you are accessing an unconfigured service and the=20 system goes belly up. Most of our services currently fall into this categ= ory.=20 The ordering in embeddor is required for current set of implementations -= if=20 we were ever to change the implementations radically we would need to rew= rite=20 the embeddor code which is a bit icky.=20 I guess we kinda do need proper manager for this stuff but I would really= like=20 to avoid the complexity of it all. Can you think of any way of avoiding a= ll=20 this complexity? > It always struck me as kinda odd that avalon doesn't have a container t= hat > does the dependency tracking thing. We have about 5 at the moment I believe ;) Unfortunately all of them are=20 monolithic or add extra layers that ant does not require. Writing a gener= ic=20 one is possible but a bit of work that has not yet been done. --=20 Cheers, Peter Donald -- To unsubscribe, e-mail: For additional commands, e-mail: