Peter, Stephen,
>>I'll leave it in your hands then. If you are too overwhelmed tell me
>>what method name you would choose and I'll do the work (after approving
>>patches through you).
>>
>
>Okay the names of the methods I was thinking about (and when they get called)
>was in that last mail I sent to Stephen and then he reforwarded to this list.
>
Here they are:-
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.
>The application startup method would accept a ApplicationEvent object (that
>had a method to return the SarMetaData).
>
>The applicationFailed() method (or whatever it was called) would then accept
>an exception and that would be the cause of application failure.
>
>Other events would have 0 parrameters.
>
ApplicationEvent
{
SarMetaData getSarMetaData();
}
BlockListener
{
// as before plus ....
void applicationStarting();
void applicationStarted(ApplicationEvent applicationEvent);
void applicationStopping();
void applicationStopped();
void applicationFailure(Exception causeOfFailure);
}
Question, should these new methods go in an interface called
ApplicationListener that extends BlockListener or not?
I go ahead with changes and submit patches back for approval once
clear/approved.
Regards,
- Paul H
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
