avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: controlling access to blocks
Date Mon, 02 Sep 2002 11:42:59 GMT

Igor Fedorenko wrote:

> I am not sure if I need lifecycle extensions as such. Block and its 
> security interceptor are tightly coupled but managed as two separate 
> units. This could be a problem but might as well be ok -- I did not 
> think much about it yet. Anyways, I'll keep extensions in mind.
> Btw, can I implement watchdog service using these lifecycle 
> extensions? Watchdog => periodically checks if a block is alive and if 
> it is not executes some recovery procedure. 

No problem.

1. create a lifecycle interface e.g. Observable (or whatever) that 
includes the operation(s) to be invoked on the target component

   public interface Observable
        // operation returns if it is alive - or whatever
        void observe();

2. create a component that will handler the objervation of the 
observable - for this you would implement the Creator interface because 
you concerned with monitoriing of a component (block) over its entire 

   public class ObserverExtension implements Creator
       public void create( Object object, Context context )
           // the object passed in is the component and the
           // context object contains whatever you declared that
           // the extension needs
           // maybe setup a thread at this point the periodically
           // pings the object and return - the runnable object you
           // create would include the maintenance procedures

           if( object instanceof Observable )
               // setup the monitor
               // complain to the container

       public void destroy( Object object, Context context )
           // this is where you would terminate the thread and
           // relase resources because the object is being destroyed

The excalibur/container package only contains the container independent 
aspects of this model - namely the interfaces Creator and Accessor 
together with a couple of minimal abastract classes.

If you use Merlin for this then you extension will be treated as a first 
class component (depedencies, context, cofiguration, even its own 
lifecyle extensions).  

Cheers, Steve.

> Stephen McConnell wrote:
>> Igor Fedorenko wrote:
>>> Ok, I will post a patch for cvs HEAD later this coming week.
>>> Btw, this stuff needs a little bit more from interceptor support then I
>>> originally thought. Specifically jaas interceptor must access BlockInfo
>>> somehow my guess through "Contextualizable" interface. It also needs to
>>> be Initializable/Startable. In other words, interceptors need lifecycle
>>> support as any other block (interceptor's lifecycle is couple with
>>> lifecycle of its block, so implementation might get tricky). Should I
>>> resubmit "interceptor patch" with this added functionality or should I
>>> wait for you to check interceptor support in and extend it after that?
>> You may want to take a look at the lifecycle extensions work that has 
>> been completed between the Merlin and Fortress projects. The Merlin 
>> implementation provides complete support for the establishment of 
>> extensions that are themselves components and as such receive full 
>> lifecycle handling prior to their application towards a component 
>> (block).
>> http://jakarta.apache.org/avalon/excalibur/container/extension.html
>> Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

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

View raw message