Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 9650 invoked from network); 14 Jun 2002 06:05:17 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 14 Jun 2002 06:05:17 -0000 Received: (qmail 8818 invoked by uid 97); 14 Jun 2002 06:05:29 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 8801 invoked by uid 97); 14 Jun 2002 06:05:28 -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 8787 invoked by uid 98); 14 Jun 2002 06:05:28 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3D0986D0.6030800@apache.org> Date: Fri, 14 Jun 2002 08:01:52 +0200 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org Organization: Apache Software Foundation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon Developers List Subject: Re: Draft implementation: Custom Marker Proposal References: <1023979762.2124.42.camel@lsd.bdv51> <20020613105312.GA31689@fztig938.bank.dresdner.net> <1023979762.2124.42.camel@lsd.bdv51> <5.1.0.14.2.20020614090340.00bbe420@mail.optushome.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Peter Donald wrote: > Howdy ho, > > At 06:01 PM 6/13/2002 +0200, you wrote: > >> Or, are you saying we should make the startup phase immutable and >> not extendable, but allow for access level extensions ? > > > +1 > > I spent ages trying to get this work. We went through several iterations > of Phoenix trying to enable this but it was an absolute PITA and massive > headache to maintain. The way I would recomend you implement container > specific behaviour (like Instrumentation etc) is via a > Container-specific context. > > ie Phoenix has a BlockContext via which it exports extra information to > blocks (if they want it) and also will support extra functionality in > the future. > > Note that I haven't read your proposal yet but my guess would be > something like the following would work > > interface CocoonContext extend Context > { > InstrumentPoint getPoint(String name); > CocoonSession getSession(); > File getWorkDirectory(); > ///insert whatever actual parameters you need > } > > Then your instrumentable component just does something like > > abstract class AbstractCocoonInstrumentable > implements Intrumentable, COntextualizable > > void context( Context c ) > { > CocoonContext cc = (CocoonContext)c; > setPoints( cc.getPoints() ); //Or however instrumnentable works > } > > I have used the same pattern over and over again and it works well. What > do you think ? Does it work for you? Not for me :-( We have at least 2 types of interfaces: - command interfaces - service provider interfaces The first type are Initializable, Startable, Disposable, etc.., and no Context-ComponentManager can supplant them. The second type are supplantable by context-ComponentManager. In my app, I extended the lifecycle to add a Saveable (ie save()), which cannot be switched with a Context. I think we need to address the need for an easy system to enhance the Lifecycle. In James we will possibly need the Mailet interface in the lifecycle. How? -- Nicola Ken Barozzi nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: