> -----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.
Cheers, Steve.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
