avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: BlockListener and LifecycleHelper
Date Fri, 16 Nov 2001 12:49:49 GMT
Hi,

On Wed, 14 Nov 2001 05:44, Stephen McConnell wrote:
> > > > 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

not viable as listeners need to be created before blocks (Or else they will 
miss out on events). It would be logical impossibility for something to be 
created before it is created ;)

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

agreed.

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

right.

> 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).

I am not sure exactly what you are saying here. In my mind 

Facility = Listener + Block 
* Listener to map blocks who request facility to the block that provides 
facility
* Block to actually implement Facility

All logic is still in the Block as far as I can see.

> > 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.
> >
> :-)

And I think I may have stated that this is not what I do or even recomend ;)

I think it is a responsibility of the container to maintain correct 
propogation of lifecycle events. No other untrusted object should ever get a 
direct reference to the object and thus no other object should be able to 
call the lifecycle events. This is almost true in Avalon/Phoenix and will be 
fully true in the future (currently a Block can pass a reference of itself to 
another Block and that reference is not protected).

In cases where you may not have a proper secure environment or no clear 
separation between container and componentss then such defensive programming 
may become applicable but I don't think it is applicable in Phoenix ;)

> Conclusion - an object should not implement BlockListener and Block. 

agreed.

> 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
> proxy-block
> which in turn exposes application level services to dependent blocks).

exactly. So wasn't that I was saying with my BlockListener example ... hmmm 
now I am confused ... I think ;)

So are we agreeing or not ? ;)

-- 
Cheers,

Pete

-----------------------------------------------------------
 Don't take life too seriously -- 
                          you'll never get out of it alive.
-----------------------------------------------------------

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