Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 26658 invoked from network); 17 Nov 2001 13:27:05 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 17 Nov 2001 13:27:05 -0000 Received: (qmail 22647 invoked by uid 97); 17 Nov 2001 13:27:04 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 22631 invoked by uid 97); 17 Nov 2001 13:27:04 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 22620 invoked from network); 17 Nov 2001 13:27:03 -0000 From: "Stephen McConnell" To: "Avalon Developers List" Subject: RE: BlockListener and LifecycleHelper Date: Sat, 17 Nov 2001 14:27:17 +0100 Message-ID: <000201c16f6b$93d26eb0$0a01a8c0@osm.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200111162302.fAGN2w215593@mail016.syd.optusnet.com.au> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Peter Donald wrote: > On Sat, 17 Nov 2001 00:16, Stephen McConnell wrote: > > I want LifecycleHelper to invoke component lifecycle phases > > on a listener. > > right. I don't mind LogEnabled but I don't like any of the others ;) > > > You objected to this because you said that > > listener logic should reside in a block. > > I said there was no such thing as listener logic. Listeners are > just glue to stick together blocks appropriately ;) And I said that happended to by your use-case, not mine :-) > A while back I sent a lick to an article on javaworld. I bet that was a suprise for the Editor :-) > The articule basically discussed the separation between > "procedural" and "declarative" parts of a system. Can't seem > to find think at the moment ... > > Blocks are definetly the procedural part of the system. They do things. > > I see listeners as the delacarative part. Essentially they manage > rules such > as > > * "All SOAPable Blocks are exported via a SOAPServer Block" > * "All Blocks are managed by MyManager Block" > * "All Persistable Blocks are persisted by MyPersistentManager Block" > * "All RMIEnabled Blocks are exported by MyRMIExporter Block" > * "All Repository Blocks are registered with all Store Blocks" > * "All ... Blocks are ... by ... Block(s)" What your decribing here is "one-potential-set-of-semantic" that a listener may have. That set of semantics is much more fine-grained than the listener interface itself. It is also a set of semantics that has nothing to do with my application case. > 1-to-1 listeners may also be viable and this is essentially the > reason why I allow Configuration for Listeners. > > So Listeners still == Gaffer tape for Blocks ;) For your use-case, not mine! > > 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. > > no - I definetly dont agree with that ;) I'm not going to explore this one. > Blocks provide the logic and may interact/provide services to > other blocks. > Listeners are only enablers of block interaction. > > > 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. > > coposition can't be done as there is no notion of dependencies. > initialization shouldn't really be done as no listener should be > allocating any significant resources (same reason for KB'ing > dispose) Agree - I should not have included compose (my mistake). Let me outline the "component" interface that I want to see support for and the reasons why: LogEnabled - If I'm logging anything within an object that's declared as a listener, I don't want to have to set-up another logger - just want to be supplied automagically Contextualizable - this one is a little tricky - the code I have is doing validation of the environment before blocks kick in - validation needs the information about the application context (available under the application meta-data receivable under contextualization of a listener). To veto start-up, I need to be in application space (no block space) because I can throw an exception and halt/suspend start-up. There are alternative such as extending the embeddor but this means creating a different Phoenix which I want to avoid. Configurable - I'm holding my application policy here. Initializable - Because I'm following Avalon component pattern and this is the trigger to start working and I don't like changing that without having some tangible justification. Disposable - arguments are the same as initalize. > > I need to understand why your objecting to that. > > Put it this way. I see listeners as not doing any logic - they are > declarative constructs for establishing relationships. I want to know why > this will not work in your case. 1. because I am NOT wiring blocks together 2. because I don't have an alternative mechanism 3. because I object to assertion that the current listener declaration is a valid "declarative constructs for establishing relationships" (it only references a class name within the scope of the application and declares nothing about relationships) 4. because I'm dealing with application policy 5. because I'm stubborn and you haven't given me a good tangible technical argument why this is inappropriate 6. because I wanted to have a least six bullet points > So far you have only indicated that you > "want" to do logic in listeners. I want to know why the listeners as > declaratives model doesn't work in your case or makes it harder > to construct your application. So far I haven't seen any indication that > this is so ;) I'm handling application level policy. The registration of a listener is the only access point I have to plug-in an application-level facility. This is a different use-case to yours - but that does not make it invalid - just different. All I'm proposing is that IF a class, registered as a listener, exposes any of the above component interfaces, then, give the class what it needs to do its stuff correctly. Cheers, Steve. > -- > Cheers, > > Pete > > --------------------------------------------------------- > Clarke's Third Law: "Any technology distinguishable from > magic is insufficiently advanced". > --------------------------------------------------------- > > -- > To unsubscribe, e-mail: > > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: