Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 37514 invoked from network); 1 Mar 2006 15:27:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Mar 2006 15:27:14 -0000 Received: (qmail 83941 invoked by uid 500); 1 Mar 2006 15:27:52 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 83839 invoked by uid 500); 1 Mar 2006 15:27:52 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 83805 invoked by uid 99); 1 Mar 2006 15:27:52 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Mar 2006 07:27:51 -0800 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [216.136.173.32] (HELO smtp012.mail.yahoo.com) (216.136.173.32) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 01 Mar 2006 07:27:51 -0800 Received: (qmail 12499 invoked from network); 1 Mar 2006 15:27:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=TwrApqH6nf9UNEW/yyZoItiVtWHWJ/Er2c/wW3fEsIwJZ+8BKWXpaZFsuhA+PvFyVULjs9+Kvr/CQIOd3QhcA9b2iqB2VT3+y+wrP5mI8kBStOkbdTL4GWmvmj626xn4PEH7lEsIfagyQgq/egI8KrsDsA6XDIZCK6jsavJNAoY= ; Received: from unknown (HELO ?192.168.1.5?) (david?jencks@66.93.38.137 with plain) by smtp012.mail.yahoo.com with SMTP; 1 Mar 2006 15:27:30 -0000 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <44058BFB.7030801@optusnet.com.au> References: <44058BFB.7030801@optusnet.com.au> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <270654D5-E8FB-4C4A-A9D3-90544AAC3154@yahoo.com> Content-Transfer-Encoding: 7bit From: David Jencks Subject: Re: ModuleBuilder - add initENC after addGBeans Date: Wed, 1 Mar 2006 07:27:27 -0800 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.746.2) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Mar 1, 2006, at 3:56 AM, Gianny Damour wrote: > Hi, > > I think that we need to split ModuleBuilder.addGBeans into two > methods: addGBeans and initENC. addGBeans implementations perform > GBean registrations as per the current approach. initENC is invoked > after the addGBeans phase and implementations use this callback to > build the ENC. > > The issue with the current implementation is that it is impossible > to bind a GBean reference to the ENC if the referenced GBean is > defined by a module which has not yet been processed by addGBeans. > For instance, if a module A references a GBean added by a module B > and if module A is processed before module B, then it is impossible > to locate the referenced GBean as it has not yet been added to the > registry. > > If there is no objection, I will start to work on it in the next > couple of days. I would rather see us reduce the number of module builder phases than increase them :-) So far we have dealt with this problem by registering a gbean data for anything that could possibly be referenced in the ENC during the initContext phase. I'm also worried that changes of this nature could make merging the configid/1.1 changes into trunk almost impossible. What feature are you implementing that needs this that doesn't work with the current approach? Could you wait with this until the configid work is merged to trunk? thanks david jencks > > Thanks, > Gianny > >