I like the policy/meta info approach you both suggest. As Steve points out it leaves the container in a still valid state for other components/services.
Leo: You have the idea right, and your example of a security manager is a really good one! - Robert -----Original Message----- From: Stephen McConnell [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 18, 2002 5:29 AM To: Avalon Developers List Subject: Re: Migrating from ECM Leo Simons wrote: >On Wed, 2002-07-17 at 22:39, Robert wrote: > > >>You are right, and actually the container (ECM in this case) does not >>make the component available if it throws a configure exception (which >>it will). Let me try this another way :-) >>Maybe this isn't 'right', but if one component fails, then I would like >>the whole container to not service anything. Basically say that the >>container didn't configure because of component XYZ not configuring. I'm >>sure that breaks some contract or other, as it makes the container >>dependant on the components it is containing. I'm sure I can do a >>workaround, but just haven't gotten to it yet. >> >> > >Actually, sounds like it could be very useful =) > >If one component is a security manager that gets its configuration from >a database component, then if the database component fails the system >should stop, right? (not talking about whether this is a smart setup :) > >That the idea? > >I can see extending the metainfo to have a property "required" where the >container >does stuff like > >try >{ > component.configure() >} >catch( ConfigurationException ce ) >{ > log.error( "#$@*!@" ); > > if(componentMetaInfo.getAsBoolean(ComponentMetaInfo.REQUIRED)) > { > log.fatalError( > "required component not functioning properly" ); > System.exit( -1 ); > } > >} > >the question is whether this case is common enough to put it in a >container by standard or if it should require extensions. Completely >pluggable lifecycle handlers would help (which I mentioned briefly wrt >Marcus' extensible lifecycle code for fortress). > Not as a standard - but as a policy option. Given a service establishment failure (either during assembly or runtime), the container should handle the decommissioning of all components that are dependent on the failed service. This leaves you with a container that may still have other compoennt running that are not dependent on the failed component. At this point you could apply a policy of BEST_EFFORT - i.e. the container has done its best and will continue with the running system, or a policy of STRICT_COMPLIANCE where the container, on catching a failure, will decommission of the containers components. Cheers, Steve. > > > >>I really don't want to make one super component as it would be really >>ugly and wouldn't really 'fit'. Besides, I use the Excalibur connection >>pooling :-) >> >> > >:-) Didn't get what you were talking about before. What you need is not >a callback, just a metainfo extension =) > > > >>In any event, I'm by no means complaining about Avalon!! I really love >>it actually. Just thinking out loud I guess. >> >>I appreciate all the thoughts though! >> >> > >cheers! > >- Leo > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- 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]>
