Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 56069 invoked from network); 6 Jun 2002 00:59:58 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 6 Jun 2002 00:59:58 -0000 Received: (qmail 25802 invoked by uid 97); 6 Jun 2002 01:00:00 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 25531 invoked by uid 97); 6 Jun 2002 00:59:58 -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 25378 invoked by uid 98); 6 Jun 2002 00:59:57 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-Id: <5.1.0.14.2.20020606102647.00b28370@mail.optushome.com.au> X-Sender: xdonald@mail.optushome.com.au X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Jun 2002 10:51:07 +1000 To: "Avalon Developers List" From: Peter Donald Subject: RE: FW: ContainerManager and Sub-containers In-Reply-To: <003101c20c95$e749f780$ac00a8c0@Gabriel> References: <200206050946.38537.peter@apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 09:35 AM 6/5/2002 -0400, you wrote: > > I think that no matter how far you go down this path it is > > never going to be > > fast enough. IMHO the only way to do this is to lookup > > resources during > > initialization phase rather than at runtime and with a good > > assembly system > > you get all the bang of runtime lookup with little cost. > >Explain? Keep in mind I am thinking of a very dynamic system like >Cocoon where component resolution depends on the URI and any runtime >variables. So pre-bake the components. Then when you need to lookup a Generator then do class MyClass { public void service( final ServiceManager sm ) throws SE { myGeneratorManager = (GeneratorManager)sm.lookup( GeneratorManager.ROLE ); } void doRequest( ....params ...) { g = myGeneratorManager.lookup( someOptimizedKey ); g.generate(); myGeneratorManager.release( g ); } } If you notice I used the same API as current SM with an optimized key. You could replace it with something more particular to generators though. The above demonstrates an effective way IMHO to create and manage generators that as performance sensitive as you need. It also follows suit with other established scalable frameworkss (ie J2EE, CORBA) and best of all it does not inflict the rest of us with complexity. -- To unsubscribe, e-mail: For additional commands, e-mail: