And now I have updated the ContainerKit lifecyle package. Basically this helps with running components through lifecyle. It makes sure that the correct order is followed as well as adding lots more logging and error catching code.
To use this you would implement the ResourceAccessor interface. It is responsible for creating all the resources (context, serviceManager etc) for component (and also responsible for creating component itself). Each of the methods take an Object parameter. Each container is likely to pass a different object into ResourceAccessor. Phoenix passes a BlockEntry object while myrmidon will like pass in the ComponentInfo object. You use this key to lcoate resources for specifific component and away you go. If someone could have a look at rewrite ComponentFactory in Fortress to use it then that would be great. At 01:54 PM 6/6/2002 +1000, you wrote: >Hi, > >The verifier package is also something to look at now. Basically it >validates a number of rules for avalon components. Some of the rules may >not be relevent for a particular container (like requirement that classes >be public or have no args constructors) in which caseyou can overide the >particular method that checks that rule so that it is a no-op. > >Comments on the rules, which up until now have largely been unspoken rules >or only partially enforced. Feel free to disagree about them if you want ;) > >At 01:31 PM 6/6/2002 +1000, you wrote: >>Hi, >> >>I have just completed the first draft of the MetaData and MetaInfo >>objects for container writers. I would appreciate if all you container >>writers (particularly Berin, Leo and Stephen) would look at the classes in >> >>org.apache.excalibur.containerkit.metadata >>org.apache.excalibur.containerkit.metainfo >> >>The metainfo classes are meta information about the component type. >>Basically it contains information such as >>* what services does component support >>* what services does component require to operate >>* generic information (like classname of component and version of component) >> >>The metadata contains basic information about a "assembled" component. >>Basically it is the mapping of component dependencies. ie Component A >>provides service P to Component B >> >>The metainfo should be sufficient to model all our containers. When a >>container requires specific capabilities (ie Merlins constraints or >>Fortresses lifestyles) it can use "attributes". Attributes are basically >>opaque strings that describe container specific things (See javadocs of >>the classes). The metainfo classes should not need to be subclassed. >> >>In the future metainfo will probably include things like; >>* configuration/parameters schema (maybe XML Schema?) >>* required context values (Basically like resource-ref from J2EE world) >> >>The metadata package will probably need to be subclassed to provide >>container specific information but it is a start. >> >>So what do you think? Is there anything else that it needs to support for >>it to be useful in all containers? >> >> >>-- >>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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
