Stephen McConnell wrote: > > > -----Original Message----- > > From: Berin Loritsch [mailto:[EMAIL PROTECTED] > > Sent: Thursday, 12 April, 2001 18:40 > > To: Avalon Development > > Subject: Re: [vote] lifecycle exceptions > > > > > > Stephen McConnell wrote: > > > > > > Borin: > > > > > > In you last (excelent) message you proposed the following interface > > > defintions which are very close to something I think would work > > well in our > > > environment. > > > > > So, including the relevant exceptions we would end up with the following > > > interfaces: > > > > > > interface Executable { > > > void start() throws StartException; > > > void stop() throws StopException; > > > } > > > > > > interface Interruptable extends Executable { > > > void suspend() throws SuspendException; > > > void resume() throws ResumeException; > > > } > > > > > > interface Suspendable { // better name, anyone? > > > void suspend() throws SuspendException; > > > void resume() throws ResumeException; > > > } > > > > > > +1 > > > > I was actually proposing the removal of Suspendable and replacing it with > > Interruptable. Why? Because conceptually you can't suspend something > > that is not currently running. It doesn't really make sense. If you can > > give me a real use case where this would be necessary, and desirable, then > > the Interruptable interface would extend both Suspendable and Executable. > > I personally can't think of anything that would be better served in that > > manner. > > Zutt .... this was a mistake (cut and paste and not too much sleep myself). > I did not mean to include the Suspendable interface. > > > As to the addition of the exceptions, +1. > > > > > I would just like to add an additional exception, extending > > > StartException that can be thrown by a component when an attempt is > > > made to start it and it cannot start for reasons of conflict between its > > > own internal startup-mechanism and the explicit instruction to start. > > > I.e. this would allow a manager to catch the explicit exception case of > > > an autonomous startup. > > > > > > AutonomyConflictException : StartException > > > > I think you've lost me there. I've been suffering from a mild case of > > sleep depravation, so I may not be thinking clearly. Are you saying that > > Component A is already started and Component B asks it to start again? > > No. > > > In the case that Component B is responsible for directly managing > > Component A, then I can see the need to flag that Exception (although I > would like > > to see a better name for the Exception). > > Here is the actual example - we have lots of components that are activated > by a remote CORBA invocation. A thing called a POA (Portable Object > Adapter) is responsible for the startup of the component, however, the > component manager is responsible for configuration, contextualization and > initialization under a factory implementation. Startup is delegated to the > POA (using internal POA mechanisms) - i.e. POA assigns and maintains threads > and tables of active objects. I don't want the manager to be concerned about > how object startup is implemented - all the manager needs to know if (a) if > the invocation of start was successful, or (b) if the component will start > itself some other way (signalled by the AutonomyConflictException, or (c) if > the component failed to start for some other reason. In the case of the > AutonomyConflictException its not a failure - its a policy thing. I.e. there > is a conflict between the manager's request to start the component "now" as > opposed to the internal policy of the component to start under some > condition defined by its implementation (its automomouse behaviour) - as > such the component cannot start because it is acting autonimoulsy relative > to the manager.
I see. We are talking about remote Components (whether via RMI or CORBA it should not make a difference in the API). As to your points: a) if no exception was thrown, it was successful b) AutonomyConflictException--keep going with lyfecycle processing c) Other StartException--startup was unsuccessful, destroy component Is this what you are saying (in very simple practical terms as in the responsibility of Avalon)? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
