Pete: See notes in-line :-)
Steve. > -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED] > 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 proxy-block which in turn exposes application level services to dependent blocks). Cheers, Steve. Stephen J. McConnell, OSM sarl digital products for a global economy http://www.osm.net mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
