Pete: I want LifecycleHelper to invoke component lifecycle phases on a listener. You objected to this because you said that listener logic should reside in a block. I objected to that because I have "application" level logic that does not belong in a block - it belongs in the listener. I think we both agree that when logic is exposed to blocks, this done through a block acting as a proxy to the listener. What we apparently don't agree on is allowing a listener to be a component (i.e. has a lifecycle covering contextualization, composition, initialization, dispose, etc. I need to understand why your objecting to that.
Cheers, Steve. > -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED] > Sent: Friday, 16 November, 2001 13:50 > To: Avalon Developers List > Subject: Re: BlockListener and LifecycleHelper > > > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
