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? Robert -----Original Message----- From: Peter Donald [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 19, 2002 12:53 AM To: [EMAIL PROTECTED] Subject: LifecycleHelper & Verifier Hi, I am about halfway through writing the generic components to help with writing 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 component 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 component. 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 lifecycle 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/lif ecycle/* The other bit I am doing is the verifier which makes sure that the components satisfy the basic rules of avalon. ie * Roles/Services should be public interfaces that don't extend Lifecycle interfaces. * Composable+Serviceable is incompatible combination as is Parameterizable+Configurable. * implementation class should have public noargs constructor * 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 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 who have implemented their own container) to see what needs fixing then that would be apreciated. Cheers, Peter Donald -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
