avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [vote] lifecycle exceptions
Date Thu, 12 Apr 2001 17:24:48 GMT
Stephen McConnell wrote:
> 
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > 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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message