> -----Original Message-----
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 10 January, 2002 12:20
> To: Avalon Developers List
> Subject: RE: BlockListener needs more methods
>
>
>
> Peter Donald wrote:
> [on BlockListener]
> > Stephen do you recall when that was or have a pointer into the
> archives ?
>
> Pete:
>
> Here is your email to me which I have not yet replied to.
> (I was swamped by external events at the time and need to get
> my head back around this stuff - but not right now - other things
> that I have to deal with just at the moment).
However, ....
The following (you suggestion) would be "really" useful:
void applicationStarting() //before blocks are startedup
void applicationStarted() //when all blocks are started up
void applicationStopping() //before blocks are shutdown
void applicationStopped() //when all blocks are shutdown
void applicationFailure() //when application fails to load
Providing the application event gives me a hook to (a) the
ability to veto application startup and invoke shutdown, and
(b) info about the blocks contained in the application. This
would let me abandon one of two patches I have on the Avalon/
Phoenix stuff.
Cheers, Steve.
> Steve.
>
> =====================================================================
>
>
> > -----Original Message-----
> > From: Peter Donald [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, 18 November, 2001 02:23
> > To: Avalon Developers List
> > Subject: Re: BlockListener and LifecycleHelper
> >
> >
> > On Sun, 18 Nov 2001 00:27, Stephen McConnell wrote:
> > > 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 :-)
> >
> > Right but the functionality you want to implement is already
> > supported. My
> > use-case was designed for application wide aspects / policy /
> > facilities /
> > whatever. So far you have yet to say where this model breaks
> down in your
> > case. You just said it does. I need facts not opinions ;)
> >
> > So what is missing from the model I propose that would;
> > * degrade quality of implementation/design
> > * make it impossible to implement some functionality
> > etc
> >
> > The only thing I have considered is maybe that not enough events are
> > supported. It may be useful to support other events such as
> >
> > void applicationStarting() //before blocks are startedup
> > void applicationStarted() //when all blocks are started up
> > void applicationStopping() //before blocks are shutdown
> > void applicationStopped() //when all blocks are shutdown
> > void applicationFailure() //when application fails to load
> >
> > It is possible that the above may be useful to add ... not sure aty this
> > stage. (or at minimum the appStarted + appStopping)
> >
> > > > 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
> >
> > reasonable.
> >
> > > 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).
> >
> > hmmm - is this a local modification? The only thing you can get from
> > BlockContext as far as I see is the Application name and
> application dir.
> > Have you modified it locally to get other stuff?
>
> [yep - its a local modification - sorry about that]
>
> > > 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.
> >
> > Would adding notification of the events mentioned above work for this?
> >
> > > 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.
> >
> > I need to know what "work" you are doing before I can judge
> whether it is
> > something we want to support ;)
> >
> > > > > 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
> >
> > ;P
> >
> > > > 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.
> >
> > right.
> >
> > > 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.
> >
> > You still haven't really told me exactly what you want to do and why the
> > current model doesn't work for you. If LogEnabled was supported and some
> > extra events were added (like above) would you be able to
> > implement what you
> > want to implement?
> >
> > --
> > Cheers,
> >
> > Pete
>
>
> --
> 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]>
