avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert" <rmcint...@bull-enterprises.com>
Subject RE: Migrating from ECM
Date Thu, 18 Jul 2002 16:34:26 GMT
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:mcconnell@osm.net] 
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:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail:
<mailto:avalon-dev-help@jakarta.apache.org>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




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



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


Mime
View raw message