Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 20872 invoked from network); 7 Nov 2002 15:37:07 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 7 Nov 2002 15:37:07 -0000 Received: (qmail 20602 invoked by uid 97); 7 Nov 2002 15:38:02 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 20572 invoked by uid 97); 7 Nov 2002 15:38:01 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 20559 invoked by uid 98); 7 Nov 2002 15:38:00 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Content-Type: text/plain; charset="iso-8859-1" From: Peter Donald To: "Avalon Developers List" Subject: Re: ExcaliburComponentManagerServlet Date: Fri, 8 Nov 2002 02:44:26 +1100 User-Agent: KMail/1.4.2 References: <200211071828.57348.peter@apache.org> <3DCA378E.7000801@tanukisoftware.com> <3DCA518B.8060705@tanukisoftware.com> In-Reply-To: <3DCA518B.8060705@tanukisoftware.com> 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: <200211080244.26824.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, 7 Nov 2002 22:42, Leif Mortenson wrote: > Stuff started breaking again because you moved the > ComponentManager2ServiceManager > over to Framework as the WrapperServiceManager. > > That is fixed now. No problem. ops. Results from me not using Selectors ;) > What would you think about moving the ComponentProxyGenerator over as > well. Doing so would > remove the need for the Container package by the Component package (?) > Seems to make > as much sense as moving the WrapperServiceManager class. I am not sure I like it. The main reason is that there is no consensus on= how=20 proxys are generated. ie In Phoenix/Merlin the lookup key will not=20 necessarily match the interface name and thus the proxy would never work = in=20 this situation. In ECM/Fortress it works by virtue of=20 key =3D=3D role + decoration I would feel more comfortable if the code was moved either into both ECM = and=20 fortress (It would reduce coupling and thus IMHO the duplication is not b= ad).=20 However long term I would prefer that it get moved into ECM and fortress=20 implement a proper Proxy management (which included proxying objects prio= r to=20 them being made available via the SM or CM). --=20 Cheers, Peter Donald --------------------------------------------------- "It is easy to dodge our responsibilities, but we=20 cannot dodge the consequences of dodging our=20 responsibilities." -Josiah Stamp=20 ---------------------------------------------------=20 -- To unsubscribe, e-mail: For additional commands, e-mail: