avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@osm.net>
Subject RE: BlockListener and LifecycleHelper
Date Tue, 13 Nov 2001 18:44:21 GMT


See notes in-line :-)


> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Tuesday, 13 November, 2001 11:34
> To: Avalon Developers List
> Subject: Re: BlockListener and LifecycleHelper
> On Tue, 13 Nov 2001 04:52, Stephen McConnell wrote:
> > > > After playing around with the Phoenix BlockListener I decided
> > > > to transfer our human interface centric block implementation
> > > > to a block listener instance.  The resulting code is much
> > > > cleaner - however - I found some limitations with the way
> > > > LifecycleHelper handles listener instances.  Under the CVS
> > > > LifecycleHelper implementation the only component phase
> > > > handled by the helper is to configure the listener.  I want
> > > > my listener to be log enabled, contextualized, configured,
> > > > and initalized.  So, I have updated LifecycleHelper to do
> > > > exactly that by changing the startupListener method.
> > > > I though it would be worthwhile adding the updated version
> > > > to the CVS (source attached).
> > >
> > > Im not sure you are using the BlockListener in the way that I
> > > intended it to be used ;) Basically the purpose of a
> > > BlockListener in my mind is to act as an enabler for
> > > relationships between blocks (besides a dependency
> > > relationship).
> >
> > I'm looking at BlockListener as open mechanisms (open in the sence
> > that it declared in assembly.xml) though which I can plug a component
> > that monitors the starting up and shutting down of any block
> > installed in a particular sar.
> right.
> > > So it should not under any circumstances have any real logic
> > > included in it.
> >
> > BlockListener provides a clean mechanism for extension of
> > Phoenix.
> agreed. BlockListeners were intended to provide all those
> features that are not general enough to be kernel services -
> like BlockPersistence, exporting via RMI/SOAP/Other,
> exporting via a Management system or whatever.
> > While this may not have been the intent - (a) such a
> > mechanism is needed, and (b) the "no real logic" principal your
> > noted seems to be relevant to the use case you had in mind (i.e.
> > handling inter-working of blocks).
> still think it is ;)

Given an implementation that is not intended to be a service to
a block (or should not be exposed to blocks), I cannot see why a
listener should not be treated as a component.  I'm guessing that
your concern is that listeners will be created that declare
themselves as services - which I think is an inappropriate
use of the interface. I'm also guessing that your concerned about
the duplication effect created under the current implementation when
a listener is also a block.  In particular:

  1. listener only
     - no issue
  2. listener implementing the component interfaces
     - if listener does not implement block, then there
       are no obvious reasons (an none declared this list
       so far :-)) for the listener not handled in a
       component lifecycle sequence
  3. listener implementing the Block interface
     - there is a potential for conflicting execution logic
       if the same component can be subject to multiple
       lifecycle actions - this is close to what is currently
       implemented except that the configure method could be
       invoked twice (which can be handled by the
       implementation by getting the configuration name - but
       it's not a nice approach).
     - the appears to be issue concerning phasing between
       the listener's reception of events, and its readiness
       to handle these events because the block may not have
       been contextualized/configured/initalized, etc.  I.e.
       we are forcing a requirement on a combined block/listener
       to handle events independently of its execution state

> > > The Blocks should contain the logic. The Listener is just there
> > > to link the "client" blocks with the "server" block.
> >
> > In my case, the functions I am implementing under the listener is
> > not a block - it is a component that extends the functionality
> > of the Phoenix platform.
> Right. But the question is - could it be a Block? I mean - what
> would be the negative side of making it a Block and having other
> Blocks "registered" with management system. The registration (and
> unregistration) would be done via the BlockListener. Making this
> .sar wide service a Block has the advantage that other Blocks may
> choose to depend on it.

This approach blurs the issue of the object lifecycle of a listener
with the object lifecycle of a block.  I don't think a listener should
be allowed to be a block because they are orthogonal to each other.  A
listeners lifecycle is linked to the sar file and as such exists for
the lifetime of the application.  A block's lifecycle is a transient
sub-set of the application's lifecycle.

However, a block could be provided that handles the establishment
of a relationship with a listener, and that block could then provide
support to the listener and other blocks. This scenario is ok because
we are clearly separating the implementations that deal with different
phases of execution (application versus phoenix).  The ideal scenario
would be the formal specification of a "Facility" (a object
that implements Component and BlockListener).

> If the only differences between BlockListener and Block are;
> * listeners get events about other blocks
> * blocks can have dependency relationships
> then I don't see an advantage of making a distinction between the two.

All of the OSM block enforce the Avalon Component design patterns. Our
blocks will throw exceptions if attempts are made to use them outside
of the Component usage model.  Keep in mind that this isn't just
following a pattern - things like block initialisation establish
distributed service context (including principal identities, etc.).
By mixing in BlockListener we are introducing a "special case".

Berin Loritsch wrote (a couple of minutes ago)
> You should ALWAYS explicitly enforce your contracts.  This leads to
> secure components that cannot be interacted with in ways you had no
> intention of allowing.


Conclusion - an object should not implement BlockListener and Block. If
a developer wants to provide services to other blocks, he/she should provide
a proxy-block (where the listener establishes a contract with the
which in turn exposes application level services to dependent blocks).

Cheers, Steve.

Stephen J. McConnell, OSM sarl
digital products for a global economy

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

View raw message