avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert" <rmcint...@bull-enterprises.com>
Subject RE: LifecycleHelper & Verifier
Date Sun, 19 May 2002 06:19:43 GMT
A couple of simple questions:

In ResourceAccessor, you mention that the argument would be some meta
data, so would this equate to say, a Configuration object, or are/is
there going to be a MetaData structure that abstracts out these things?

I really like the idea of the LifecycleHelper. Would this potentially
move up from Phoenix?


-----Original Message-----
From: Peter Donald [mailto:peter@apache.org] 
Sent: Sunday, May 19, 2002 12:53 AM
To: avalon-dev@jakarta.apache.org
Subject: LifecycleHelper & Verifier


I am about halfway through writing the generic components to help with
your own container. The two bits I am currently working on is the 

* LifecycleHelper: Runs objects through their lifecycle phases
* Verifier: Verifys that objects satisfy basic rules of an Avalon

With LifecycleHelper you basically implement a ResourceAccessor and pass
it to 
the LifecycleHelper everytime you are processing a component. The 
ResourceAccessor takes an arbitrary parameter that you can fill with a 
container specific structure which you use to get resources for a

For instance a Phoenix Application gets passed BlockMetaData or 
BlockListenerMetaData in this parameter. While Fortress or whatever
would be 
passed its own metadata describing things like pooling size and
style. While Myrmidon is going to use another set ot metadata.

Anyways I would appreciate any feedback. it currently resides in


The other bit I am doing is the verifier which makes sure that the
satisfy the basic rules of avalon. ie 
* Roles/Services should be public interfaces that don't extend Lifecycle

* Composable+Serviceable is incompatible combination as is 
* implementation class should have public noargs constructor 
* implementation class should be public non abstract class
* implementation class should implement all services

All these rules are implemented at fine grain level so you should be
able to 
only apply the ones that are relevent for the container.

It currently resides at


Anyways if you can have a look and comment on them (particularly others
have implemented their own container) to see what needs fixing then that

would be apreciated.


Peter Donald

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message