Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 64131 invoked from network); 19 May 2002 05:53:50 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 19 May 2002 05:53:50 -0000 Received: (qmail 9402 invoked by uid 97); 19 May 2002 05:54:00 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 9349 invoked by uid 97); 19 May 2002 05:53:59 -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 9337 invoked by uid 98); 19 May 2002 05:53:58 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Content-Type: text/plain; charset="us-ascii" From: Peter Donald To: avalon-dev@jakarta.apache.org Subject: LifecycleHelper & Verifier Date: Sun, 19 May 2002 15:53:09 +1000 X-Mailer: KMail [version 1.4] 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: <200205191553.09703.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 Hi, I am about halfway through writing the generic components to help with wr= iting=20 your own container. The two bits I am currently working on is the=20 * LifecycleHelper: Runs objects through their lifecycle phases * Verifier: Verifys that objects satisfy basic rules of an Avalon compone= nt With LifecycleHelper you basically implement a ResourceAccessor and pass = it to=20 the LifecycleHelper everytime you are processing a component. The=20 ResourceAccessor takes an arbitrary parameter that you can fill with a=20 container specific structure which you use to get resources for a compone= nt.=20 For instance a Phoenix Application gets passed BlockMetaData or=20 BlockListenerMetaData in this parameter. While Fortress or whatever would= be=20 passed its own metadata describing things like pooling size and lifecycle= =20 style. While Myrmidon is going to use another set ot metadata. Anyways I would appreciate any feedback. it currently resides in jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/life= cycle/* The other bit I am doing is the verifier which makes sure that the compon= ents=20 satisfy the basic rules of avalon. ie=20 * Roles/Services should be public interfaces that don't extend Lifecycle=20 interfaces.=20 * Composable+Serviceable is incompatible combination as is=20 Parameterizable+Configurable. * implementation class should have public noargs constructor=20 * implementation class should be public non abstract class * implementation class should implement all services etc. All these rules are implemented at fine grain level so you should be able= to=20 only apply the ones that are relevent for the container. It currently resides at jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/tools/verifier/= Verifier.java Anyways if you can have a look and comment on them (particularly others w= ho=20 have implemented their own container) to see what needs fixing then that=20 would be apreciated. Cheers, Peter Donald -- To unsubscribe, e-mail: For additional commands, e-mail: