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]>
