You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <ma...@leosimons.com> on 2001/04/10 10:11:13 UTC
[vote] lifecycle exceptions
proposal:
For 4.0 of the framework code, CascadingException
is updated to extend RuntimeException, and new exceptions
are created for all lifecycle methods except run(), stop()
and dispose().
So:
contextualize() throws ContextualizationException
init() throws InitializationException
etc.
For:
- existing code has already proven the exceptions are
neccessary. We need to add them.
- making use of RuntimeException means that existing code
will be able to compile and run if the exceptions are
not actually thrown.
- since the lifecycle exceptions are indeed (almost
always) runtime exceptions, this setup is also
correct.
Against:
- a significant body of existing code that uses avalon will
have to be updated to work with the new release (OTOH, it
will be a lot more work to change this later).
- does Cocoon2 have the time to update to this before the
beta? (if not, I propose the same change for 4.1)
cheers!
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Leo Simons <ma...@leosimons.com>:
> proposal:
> For 4.0 of the framework code, CascadingException
> is updated to extend RuntimeException, and new exceptions
> are created for all lifecycle methods except run(), stop()
> and dispose().
+1
> So:
> contextualize() throws ContextualizationException
> init() throws InitializationException
> etc.
>
> For:
> - existing code has already proven the exceptions are
> neccessary. We need to add them.
> - making use of RuntimeException means that existing code
> will be able to compile and run if the exceptions are
> not actually thrown.
> - since the lifecycle exceptions are indeed (almost
> always) runtime exceptions, this setup is also
> correct.
>
> Against:
> - a significant body of existing code that uses avalon will
> have to be updated to work with the new release (OTOH, it
> will be a lot more work to change this later).
> - does Cocoon2 have the time to update to this before the
> beta? (if not, I propose the same change for 4.1)
We must have the time to do it :) (even if I had to do it myself) I think it
completes the framework and thus needs to go into the beta for the framework.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
>
> proposal:
> For 4.0 of the framework code, CascadingException
> is updated to extend RuntimeException, and new exceptions
> are created for all lifecycle methods except run(), stop()
> and dispose().
>
> So:
> contextualize() throws ContextualizationException
> init() throws InitializationException
> etc.
>
> For:
> - existing code has already proven the exceptions are
> neccessary. We need to add them.
> - making use of RuntimeException means that existing code
> will be able to compile and run if the exceptions are
> not actually thrown.
> - since the lifecycle exceptions are indeed (almost
> always) runtime exceptions, this setup is also
> correct.
I vote +1. It is needed, and most applications with critical
service requirements (Cocoon included) catch all runtime
exceptions before the system shuts itself down.
> Against:
> - a significant body of existing code that uses avalon will
> have to be updated to work with the new release (OTOH, it
> will be a lot more work to change this later).
Really, the only time we need to change existing code, is when
we are trying to catch exceptions that would kill running threads.
> - does Cocoon2 have the time to update to this before the
> beta? (if not, I propose the same change for 4.1)
There isn't alot to update, and Cocoon 2 already handles runtime
exceptions from multiple sources--adding another one won't change
it's operation.
Cocoon 2 is on the same general release schedule as Avalon.
So lets get Avalon stabilized with NEEDED features (which this
qualifies) so Cocoon will follow shortly.
>
> cheers!
>
> LSD
>
> <java:sig>
> About LSD = new PersonalInfo();
> LSD.name("Leo Simons");
> LSD.email("mail@leosimons.com");
> LSD.URL( [
> http://www.leosimons.com, // personal website
> http://www.atfantasy.com, // fantasy RPG portal
> http://www.the-sign.nl // web-design company
> ] );
> LSD.quote("Buh!");
> email.setSig((String)LSD);
> </java:sig>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
Peter Donald wrote:
>
> At 10:11 10/4/01 +0200, Leo Simons wrote:
> >proposal:
> >For 4.0 of the framework code, CascadingException
> >is updated to extend RuntimeException,
>
> -1
>
> Whats wrong with CascadingRuntimeException???
>
> >and new exceptions
> >are created for all lifecycle methods except run(), stop()
> >and dispose().
>
> -1 for run
> +1 for stop/start/resume/suspend/etc
> +/-0 for dispose() (it will be ignored anyway)
>
> >
> >So:
> >contextualize() throws ContextualizationException
>
> How about ContextException?
>
> >init() throws InitializationException
>
> how about initialize() throws InitializationException ? ;)
>
Lets avoid verylongandhardtotypeExceptionNames:
ContextException, InitException?
> >For:
> >- making use of RuntimeException means that existing code
> > will be able to compile and run if the exceptions are
> > not actually thrown.
>
> Short term benefit is not worth the long term negative effects IMO
>
> >- since the lifecycle exceptions are indeed (almost
> > always) runtime exceptions, this setup is also
> > correct.
>
> What makes you so sure. I have gone out of my way to make all lifecycle
> exceptions not RuntimeExceptions ;)
I agree with Peter here (I think). If a change needs doing, lets do it
properly first time. Also, lets keep RuntimeExceptions for, well,
Runtime Exceptions!
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
>
> Excellent analysis here, Berin!
> > Basically, we would have an interface for the Command object like this:
> >
> > interface Command {
> > void execute();
> > }
> >
> > We would either provide a CommandQueue, or have that command object start
> > after the Component it affects is fully set up.
>
> I'm for the latter...It makes sense to have the managing object worry about
> how to start the commands. So
>
> // ...
> myComponent.init();
> myComponent.start(); // or should this go after getCommands()?
> Iterator commands = ((Commandable)myComponent).getCommands();
> for(commands.hasNext()) {
> myThreadPool.add(new WorkerThread(commands.next()));
> }
> myComponent.run();
> myThreadPool.runAll();
> myComponent.interrupt(); // component is responsible for interrupting
> // Commands if that is neccessary
> myComponent.resume(); // component is responsible for resuming interrupted
> // commands
> myComponent.stop();
>
> // ... shutdown
> myThreadPool.stopAll(); // guaranteed before dispose()
> myThreadPool.disposeAll(); // guaranteed before dispose()
> myComponent.dispose();
> myComponent = null;
> myThreadPool = null; // last reference gone
> System.gc();
> // ...
I aggree that the commands should be executed after the Component has been
fully set up (that means after start()), and run then. I am not sure where
the myComponent.run() comes from. The start() would tell the Component to
begin (meaning background threads, etc).
> is possible. In the above (which will work with Phases in practice),
> Command would have to look like this:
>
> interface Command extends Runnable { // or we could extend Thread,
> // which means even more options
> // but also a more heavyweight
> // solution.
> void run() throws CascadingRuntimeException;
> }
I think Runnable is better. It does not force implementation issues on
the user. Thread objects are inherently run once.
> which would allow re-use of std pooling systems. It needs to be
> guaranteed that getCommands() is called after start() but before
> run(), and that the run() of the returned commands is called
> right after the run() of the component (I'm not sure this is the
> right place for those methods; important is that their point of
> execution is clearly defined).
>
> This setup has maximum flexibility while allowing complete
> manageability. I'm kinda wondering why the Command pattern was
> removed from the code...
Remember that a pattern does not mean a framework. The approach
I proposed is setting up a framework. The Timer/Scheduler Block
that was originally in Avalon was not very flexible, and the
Command object was called Alarm. When the time came for the code
to run, the Alarm object was executed. Very simple, but again,
not a framework feature.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] lifecycle exceptions
Posted by Leo Simons <ma...@leosimons.com>.
Excellent analysis here, Berin!
> interface Interruptable extends Executable {
+1
> Regarding the case where something is "startable" with no direct
> control over
> when it stops, I want to promote the "Command" pattern.
+1. Agreeing one hundred percent here - this is the best solution
I know for long-running threads.
> Basically, we would have an interface for the Command object like this:
>
> interface Command {
> void execute();
> }
>
> We would either provide a CommandQueue, or have that command object start
> after the Component it affects is fully set up.
I'm for the latter...It makes sense to have the managing object worry about
how to start the commands. So
// ...
myComponent.init();
myComponent.start(); // or should this go after getCommands()?
Iterator commands = ((Commandable)myComponent).getCommands();
for(commands.hasNext()) {
myThreadPool.add(new WorkerThread(commands.next()));
}
myComponent.run();
myThreadPool.runAll();
myComponent.interrupt(); // component is responsible for interrupting
// Commands if that is neccessary
myComponent.resume(); // component is responsible for resuming interrupted
// commands
myComponent.stop();
// ... shutdown
myThreadPool.stopAll(); // guaranteed before dispose()
myThreadPool.disposeAll(); // guaranteed before dispose()
myComponent.dispose();
myComponent = null;
myThreadPool = null; // last reference gone
System.gc();
// ...
is possible. In the above (which will work with Phases in practice),
Command would have to look like this:
interface Command extends Runnable { // or we could extend Thread,
// which means even more options
// but also a more heavyweight
// solution.
void run() throws CascadingRuntimeException;
}
which would allow re-use of std pooling systems. It needs to be
guaranteed that getCommands() is called after start() but before
run(), and that the run() of the returned commands is called
right after the run() of the component (I'm not sure this is the
right place for those methods; important is that their point of
execution is clearly defined).
This setup has maximum flexibility while allowing complete
manageability. I'm kinda wondering why the Command pattern was
removed from the code...
cheers,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Peter Donald <do...@apache.org>.
At 08:12 16/4/01 -0400, Berin Loritsch wrote:
>> I haven't renamed Composer yet, and am unsure if it
>> is neccessary.
>
>It probably isn't necessary. I proposed Composable
>so that it would be consistent with the rest of the
>*able interfaces.
Composable works for me ... and it is automatable to convert so I would be
+0.5 on it ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
>
> I've updated the proposal based on our discussions.
> Executable extends Startable and Stoppable, which
> have been deprecated. Same goes for Interuptable,
> Suspendable and Resumable, respectively.
> I think this setup satisfies all concerns in the
> best way possible (I'm hoping Pete can live with
> the deprecation warnings =).
Cool. Just make sure that Startable inherits from
Stoppable to ensure that you never have a start()
without a stop().
> I haven't renamed Composer yet, and am unsure if it
> is neccessary.
It probably isn't necessary. I proposed Composable
so that it would be consistent with the rest of the
*able interfaces.
> I've also added the Command and Commandable interfaces
> Berin suggested.
Cool.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] lifecycle exceptions
Posted by Leo Simons <ma...@leosimons.com>.
I've updated the proposal based on our discussions.
Executable extends Startable and Stoppable, which
have been deprecated. Same goes for Interuptable,
Suspendable and Resumable, respectively.
I think this setup satisfies all concerns in the
best way possible (I'm hoping Pete can live with
the deprecation warnings =).
I haven't renamed Composer yet, and am unsure if it
is neccessary.
I've also added the Command and Commandable interfaces
Berin suggested.
Now we need to update the documentation...
regards,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] lifecycle exceptions
Posted by Leo Simons <ma...@leosimons.com>.
> I don't think that ;) But I have used Stoppable throughout my code fairly
> regularly. As startable/stoppable can be called multiple times in
> lifecycle
Ooh. Is that true? Why? It seems to me that any place where you do this
it is better to use suspend/resume instead.
> there are many cases where I will stop something and then start it up
> again. The typical use case of stop involves clearing out caches but my
> start methods would always be empty. I am not sold on it - it is
> just going
> to be an absolute PITA for me to use because I have to change massive
> amounts of code to add in blank methods ;) (And I can't automate
> it safely).
Actually, doing it completely correctly probably means you'll have to
do even more refactoring to make use of Commands and where those are
not neccessary suspend() and resume()...
motivation:
-----------
start() is the parallel method for the one in Thread. As such, it is there
to call run() (this is not how it is/should be used in practice but
is what it indicates). run() itself should only be called once in the
lifetime of a thread/component, while a wait()/suspend() should be called
on it before clearing the cache and a notify()/resume() after that
to continue the work.
I actually believe that the best setup is to have a cache as a separate
thread, and a cachemanager as another separate (daemon) thread, both
living within a component. To clear the cache, the component should call
a method on the manager, without having to stop() itself. If data needs
to be synchronized, well, then it should be synchronized.
In other words, your current setup is probably not optimal (not flawed
but not the best one either); Avalon should promote and enforce the
best setup.
regards,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Peter Donald <do...@apache.org>.
At 08:55 13/4/01 -0400, Berin Loritsch wrote:
>> Looks good to me but how about we do it via
>>
>> interface Executable extends Startable, Stoppable {}
>> interface Interruptable extends Suspendable, Resumable, Executable {}
>>
>> This would leave the issue more open for people who have done it that way
>> in past.
>
>I think you missed the whole analysis I presented on why I came
>up with this approach in the first place. You are always telling
>us to prove it to you why we think something, now I am asking that
>of you. In what circumstance would something be Startable but
>not Stoppable? A _real_ use case. Also, I want to know why you
>think it would have to be Startable without being Stoppable instead
>of using the Command pattern I proposed.
I don't think that ;) But I have used Stoppable throughout my code fairly
regularly. As startable/stoppable can be called multiple times in lifecycle
there are many cases where I will stop something and then start it up
again. The typical use case of stop involves clearing out caches but my
start methods would always be empty. I am not sold on it - it is just going
to be an absolute PITA for me to use because I have to change massive
amounts of code to add in blank methods ;) (And I can't automate it safely).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> At 12:40 12/4/01 -0400, Berin Loritsch wrote:
> >> interface Executable {
> >> void start() throws StartException;
> >> void stop() throws StopException;
> >> }
> >>
> >> interface Interruptable extends Executable {
> >> void suspend() throws SuspendException;
> >> void resume() throws ResumeException;
> >> }
>
> Looks good to me but how about we do it via
>
> interface Executable extends Startable, Stoppable {}
> interface Interruptable extends Suspendable, Resumable, Executable {}
>
> This would leave the issue more open for people who have done it that way
> in past.
I think you missed the whole analysis I presented on why I came
up with this approach in the first place. You are always telling
us to prove it to you why we think something, now I am asking that
of you. In what circumstance would something be Startable but
not Stoppable? A _real_ use case. Also, I want to know why you
think it would have to be Startable without being Stoppable instead
of using the Command pattern I proposed.
Please, I am really curious to know where you are coming from. I
have wracked my brains trying to come up with a plausible scenario.
In a centrally managed environment, not being able to stop a renegade
process because it doesn't implement Stoppable is unnacceptable.
Every Executable component needs to start and stop itself in a sane
manner. It is CRITICAL if we are employing mission critical
quality servers.
We need to enforce QoS (Quality of Service) by design just as UNIX
inforces security by design. It does not mean that we automatically
have QoS, but we have the framework to require it.
I think that separating the Startable, Stoppable, Suspendable, Resumable
interfaces like they are now is simply "feature" bloat. Worse, it is
the type of feature bloat that will introduce undocumented "features"
that are almost impossible to track down in a complex system.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] lifecycle exceptions
Posted by Leo Simons <ma...@leosimons.com>.
Me:
> > myComponent.start(); // or should this go after getCommands()?
> > Iterator commands = ((Commandable)myComponent).getCommands();
> > for(commands.hasNext()) {
> > myThreadPool.add(new WorkerThread(commands.next()));
> > }
> > myComponent.run();
>
Berin:
> I aggree that the commands should be executed after the Component has been
> fully set up (that means after start()), and run then. I am not
> sure where
> the myComponent.run() comes from. The start() would tell the Component to
> begin (meaning background threads, etc).
It needs to be taken care of because it is/can be part of the lifecycle
process and it is possible for a component to implement both start() and
run().
Peter:
> interface Executable extends Startable, Stoppable {}
> interface Interruptable extends Suspendable, Resumable, Executable {}
>
> This would leave the issue more open for people who have done it that way
> in past.
-1
It will also mean it is a lot more likely that 'legacy' components will not
get updated. We're doing a major version change, and if we don't do it now
(remove Startable and Stoppable) it'll take a long time before we can.
Why that is bad? - management becomes more complicated than it has to be
and also less fail-safe.
A compromise would be to do it this way and deprecate Startable and
Stoppable
so they can be removed from 4.1. I personally would rather deprecate them
right
now and remove them from 4.0.
greetz,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Peter Donald <do...@apache.org>.
At 12:40 12/4/01 -0400, Berin Loritsch wrote:
>> interface Executable {
>> void start() throws StartException;
>> void stop() throws StopException;
>> }
>>
>> interface Interruptable extends Executable {
>> void suspend() throws SuspendException;
>> void resume() throws ResumeException;
>> }
Looks good to me but how about we do it via
interface Executable extends Startable, Stoppable {}
interface Interruptable extends Suspendable, Resumable, Executable {}
This would leave the issue more open for people who have done it that way
in past.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] lifecycle exceptions
Posted by Stephen McConnell <mc...@osm.net>.
[snip]
> 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
CORRECT
> b) AutonomyConflictException--keep going with lyfecycle processing
CORRECT
> c) Other StartException--startup was unsuccessful, destroy component
CORRECT
> Is this what you are saying (in very simple practical terms as in
> the responsibility of Avalon)?
Yep :-)
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Berin Loritsch <bl...@apache.org>.
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
RE: [vote] lifecycle exceptions
Posted by Stephen McConnell <mc...@osm.net>.
> -----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.
Cheers, Steve.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Berin Loritsch <bl...@apache.org>.
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.
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?
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).
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] lifecycle exceptions
Posted by Stephen McConnell <mc...@osm.net>.
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.
Borin wrote:
> So my final proposal for the runtime interfaces is this:
>
> interface Executable {
> void start();
> void stop();
> }
>
> interface Interruptable extends Executable {
> void suspend(); // should this be interrupt()?
> void resume();
> }
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 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
Cheers, Steve.
Re: [vote] lifecycle exceptions
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> >From Pete:
> -1 Some things are startable without being stoppable and vice versa.
Please read my entire message below. I will provide a separate pattern
that we could/should adopt for startable() but not stoppable(). It
just doesn't make any sense to stop something you never started, so
the stoppable really shouldn't be alone.
> >From Steve:
> > startable but not stoppable == dangerous, -1
> > stoppable but not startable == autonomous and manageable, 0
> >
> > We could define this as:
> >
> > interface Stoppable
> > {
> > void stop() throws StopException;
> > }
> >
> > interface Startable : Stoppable
> > {
> > void start() throws StartException;
> > }
Ok. This is my best stab to voice arguments and provide a possible direction.
The approach Steve is using for his Components is somewhat like the "Composite"
pattern described in Addison-Wesley's book on design patterns. Basically, it is
easier to have all managed components controled by a managing component to use
the same interface (Stoppable) and simply call the stop() method that is guaranteed
to be there for all managed components.
This is a very valid approach, and makes things like constructing new Compound
Composites (Composites that include Composites) very easy to do. Our interfaces
should strive to allow an implementation neutral view of the world (as much as
is possible).
Peter's approach is that he has some components that he has designed execute for
a specific amount of time, and then die naturally. I think there is a different
approach for this that would be beneficial.
So we have to decide pros and cons for separating start() and stop() interfaces.
Interface Pros Cons
---------------------------------------------------------------------------------
start() without stop() (1) Allows for letting a (1) Not very manageable,
thread run until it the thread is still
dies naturally running when the manging
component is stopped()
---------------------------------------------------------------------------------
stop() without start() (1) Easily allows for (1) No practical cons, only
Composites to cleanliness of API issues
propogate the stop()
to all children
---------------------------------------------------------------------------------
stop() and start() (1) Allows for any kind (1) Does not guarantee
separated creational or manageability
behavioral pattern
---------------------------------------------------------------------------------
start() and stop() (1) Guarantees (1) These two actions are
combined manageability inextricably tied to
(2) Easily allows for each other
Composites to
propogate the events
to all children
---------------------------------------------------------------------------------
Given the pros and cons, I beleive in the end that it is MOST correct to tie
the start() and stop() methods together. In a server environment, predictability
and maintainability are very strong concerns. There is another pattern that
better suits Peter's needs.
In fact, when looking at the possible needs for the runtime interfaces
(Startable, Stoppable, Suspendable, Resumable), they should be natural
pairs.
1) Startable and Stoppable should be combined for maintenance and
management reasons.
2) Suspendable and Resumable are another natural pair.
3) Conceptually speaking, you can't have Suspendable/Resumable without
Startable/Stoppable.
So my final proposal for the runtime interfaces is this:
interface Executable {
void start();
void stop();
}
interface Interruptable extends Executable {
void suspend(); // should this be interrupt()?
void resume();
}
Regarding the case where something is "startable" with no direct control over
when it stops, I want to promote the "Command" pattern. Basically you have
an object that acts as a proxy for an asynchronous process that must run to
completion. The runtime interfaces are mainly for classes that will run for
the entire duration that the Component allows it (i.e. the entire time between
start() and stop() minus the times it is interrupted). This means that we
must explicitly start and stop the process--it is an active component.
The "Command" pattern encapsulates an action or set of actions in a command
object that many times is run asynchronously (though not necessarily). The
"Command" pattern has a real need in many contexts from servers to Servlets.
In fact, the original Timer code that Federico committed used this pattern.
Basically, we would have an interface for the Command object like this:
interface Command {
void execute();
}
We would either provide a CommandQueue, or have that command object start
after the Component it affects is fully set up. The main point of the
Command object is that it is lightweight and it is tightly coupled to
a Component.
A component would have to expose, or register, this command object that
would have access to protected members. I envision something like this:
interface Commandable {
Command[] getCommands();
}
If a Component is Commandable, then the Commands can be executed between
the time the Component is fully Initialized adn the time the Component
is Disposed.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] lifecycle exceptions
Posted by Stephen McConnell <mc...@osm.net>.
There is quick summary below of clear consensus on the implication of
Stoppable and Startable interfaces. Perhaps it would be a good idea for the
rationale for the respective positions to be put forward in more detail. In
my comment I noted that a non-stoppable component is not desirable and that
Startable should inherit from Stoppable. Berin suggested the inverse -
Stoppable inheriting from Startable which suggests that there are reasons
that a component must be started in order to be stopped -- Berin, can you
explain.
The assumptions I'm making are:
- I am currently using dynamic components that start themselves in
response to external events
- however, they are still within the scope of whatever is managing
them, and if the manager is stoppable, then all managed components
must also be stoppable .. as such I have a case for Stoppable as
an independent interface and Startable as an interface inheriting
from Stoppable
Looking forward to receiving other opinions on this.
Cheers, Steve.
>From Leo:
> > >interface Startable { // better name, anyone?
> > > void start() throws StartException;
> > > void stop() throws StopException; // new
> > >}
>From Pete:
-1 Some things are startable without being stoppable and vice versa.
>From Berin:
> I agree. But have Stoppable inherit from Startable because you
> can't have Stoppable without Startable.
>From Steve:
> startable but not stoppable == dangerous, -1
> stoppable but not startable == autonomous and manageable, 0
>
> We could define this as:
>
> interface Stoppable
> {
> void stop() throws StopException;
> }
>
> interface Startable : Stoppable
> {
> void start() throws StartException;
> }
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Thursday, 12 April, 2001 15:11
> > To: Avalon Development
> > Subject: Re: [vote] lifecycle exceptions
> >
> >
> > Peter Donald wrote:
> >
> > > >|-- ContextException <-- ContextualizationException // new;
> > > >have both or
> > > >have one...which one?
> > >
> > > What Berin said
> > >
> > > ContextException if Context.get() raises it else
> > ContextualizationException
> >
> > What is the source of the error? Is it that the Context fails while
> > attempting to retrieve an object, or is it that the Component can't find
> > an object it is looking for?
> >
> > If it is the previous: ContextException
> > If it is the latter: ContextualizationException
>
> My understanding is that this is an exception raised as a result of
> executing or attempting to execute the contextualization phase and that
> ContextualizationException can be raised in event of things like (a)
> insufficient context information, (b) conflicting context information, (c)
> internal problems established by an implementation when dealing with
> supplied context information. As such this should be named
> ContextualizationException and not ContextException.
Cool. Gotcha. This is good stuff, and should make it in the Javadocs
for the class. Now I know where you are coming from.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] lifecycle exceptions
Posted by Stephen McConnell <mc...@osm.net>.
Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, 12 April, 2001 15:11
> To: Avalon Development
> Subject: Re: [vote] lifecycle exceptions
>
>
> Peter Donald wrote:
>
> > >|-- ContextException <-- ContextualizationException // new;
> > >have both or
> > >have one...which one?
> >
> > What Berin said
> >
> > ContextException if Context.get() raises it else
> ContextualizationException
>
> What is the source of the error? Is it that the Context fails while
> attempting to retrieve an object, or is it that the Component can't find
> an object it is looking for?
>
> If it is the previous: ContextException
> If it is the latter: ContextualizationException
My understanding is that this is an exception raised as a result of
executing or attempting to execute the contextualization phase and that
ContextualizationException can be raised in event of things like (a)
insufficient context information, (b) conflicting context information, (c)
internal problems established by an implementation when dealing with
supplied context information. As such this should be named
ContextualizationException and not ContextException.
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> >|-- ContextException <-- ContextualizationException // new; have both or
> >have one...which one?
>
> What Berin said
>
> ContextException if Context.get() raises it else ContextualizationException
What is the source of the error? Is it that the Context fails while
attempting to retrieve an object, or is it that the Component can't find
an object it is looking for?
If it is the previous: ContextException
If it is the latter: ContextualizationException
> >|-- CompositionException // new
>
> Considering this is used by multiple things (Selectors as well) I think we
> should stick to ComponentException
+1 ComponentException.
> >|
> >|-- ConfigurationException
> >|
> >\-- InitializationException // new
> >
> >interface Startable { // better name, anyone?
> > void start() throws StartException;
> > void stop() throws StopException; // new
> >}
>
> -1 Some things are startable without being stoppable and vice versa.
I agree. But have Stoppable inherit from Startable because you
can't have Stoppable without Startable.
> >interface Suspendable { // better name, anyone?
> > void suspend() throws SuspendException;
> > void resume() throws ResumeException; // new
> >}
>
> +1 if we can think of a better name.
How about "Interruptable"?
The term "interrupt" has the connotation of a temporary suspension of
current action that will be resumed later. Note, this does not always
happen, and it should be legal to stop() a stoppable when a class is
interrupted.
The analogy is when two people are having a conversation, and a third
comes and interrupts the conversation. In most cases, the conversation
will resume after the interrupt--but sometimes the interruption causes
the conversation to end (e.g. two siblings are talking, their dad
interrupts them and tells them to go clean their room--the conversation
is now terminated).
>
> >abstract class ClassImplementingAllLifecycleMethods implements
> > Loggable
> > Contexualizable,
> > Composable, // name change
> > Configurable
> > Initializable
> > Startable
> > Runnable
> > Suspendable
> > Recontextualizable
> > Recomposable
> > Reconfigurable
> > Disposable
> >{
> > void setLogger( Logger logger ); // does this need a different name?
>
> Can you think of a better one?
>
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] lifecycle exceptions
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
[snip]
> >interface Startable { // better name, anyone?
> > void start() throws StartException;
> > void stop() throws StopException; // new
> >}
>
> -1 Some things are startable without being stoppable and vice versa.
startable but not stoppable == dangerous, -1
stoppable but not startable == autonomous and manageable, 0
We could define this as:
interface Stoppable
{
void stop() throws StopException;
}
interface Startable : Stoppable
{
void start() throws StartException;
}
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] lifecycle exceptions
Posted by Peter Donald <do...@apache.org>.
At 05:13 11/4/01 +0200, Leo Simons wrote:
>Okay. It seems there is broad support for the
>changes. I believe this is the setup that has
>the most support:
>
>RuntimeException
>^
>|
>CascadingRuntimeException // new
>^
>|-- StartException // new
>|
>|-- StopException // new
>|
>|-- SuspendException // new
>|
>\-- ResumeException // new
+1
>Exception
>^
>|
>CascadingException
>^
>|-- ContextException <-- ContextualizationException // new; have both or
>have one...which one?
What Berin said
ContextException if Context.get() raises it else ContextualizationException
>|-- CompositionException // new
Considering this is used by multiple things (Selectors as well) I think we
should stick to ComponentException
>|
>|-- ConfigurationException
>|
>\-- InitializationException // new
>
>interface Startable { // better name, anyone?
> void start() throws StartException;
> void stop() throws StopException; // new
>}
-1 Some things are startable without being stoppable and vice versa.
>interface Suspendable { // better name, anyone?
> void suspend() throws SuspendException;
> void resume() throws ResumeException; // new
>}
+1 if we can think of a better name.
>abstract class ClassImplementingAllLifecycleMethods implements
> Loggable
> Contexualizable,
> Composable, // name change
> Configurable
> Initializable
> Startable
> Runnable
> Suspendable
> Recontextualizable
> Recomposable
> Reconfigurable
> Disposable
>{
> void setLogger( Logger logger ); // does this need a different name?
Can you think of a better one?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] lifecycle exceptions
Posted by Stephen McConnell <mc...@osm.net>.
> Okay. It seems there is broad support for the
> changes. I believe this is the setup that has
> the most support:
>
> RuntimeException
> ^
> |
> CascadingRuntimeException // new
> ^
> |-- StartException // new
> |
> |-- StopException // new
> |
> |-- SuspendException // new
> |
> \-- ResumeException // new
+1
> Exception
> ^
> |
> CascadingException
> ^
> |-- ContextException <-- ContextualizationException // new; have both or
> have one...which one?
-1 for ContextException
+1 for ContextualizationException
> |
> |-- CompositionException // new
> |
> |-- ConfigurationException
> |
> \-- InitializationException // new
+1
> interface Startable { // better name, anyone?
> void start() throws StartException;
> void stop() throws StopException; // new
> }
+1
> interface Suspendable { // better name, anyone?
> void suspend() throws SuspendException;
> void resume() throws ResumeException; // new
> }
+1
> abstract class ClassImplementingAllLifecycleMethods implements
> Loggable
> Contexualizable,
> Composable, // name change
> Configurable
> Initializable
> Startable
> Runnable
> Suspendable
> Recontextualizable
> Recomposable
> Reconfigurable
> Disposable
> {
> void setLogger( Logger logger ); // does this need a different name?
> void contexualize( Context context ) throws
> ContextualizationException;
> void compose( ComponentManager cm ) throws CompositionException;
> void configure( Configuraion conf ) throws ConfigurationException;
> void initialize() throws InitializationException; // name change
> void start(); // might throw exception
> void run(); // doesn't throw exception
> void suspend(); // might throw exception
> void recontextualize( Context context ) throws
> ContextualizationException;
> void recompose( ComponentManager cm ) throws
> CompositionException;
> void reconfigure( Configuration conf ) throws
> ConfigurationException;
> void resume(); // might throw exception
> void stop(); // might throw exception
> void dispose(); // doesn't throw exception
> }
>
> any other suggestions/ -1s?
Looks good!
> cheers,
>
> LSD, who is now sure nobody on this list cares about versioning
> so will start bugging said list about it when neccessary
What was the reason for odd version signifying beta as distict from
1.2a (means alpha), 1.2b (means beta), or 7.5 (means released).
What was suggested did not seem intuative to me.
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] lifecycle exceptions
Posted by Leo Simons <ma...@leosimons.com>.
Okay. It seems there is broad support for the
changes. I believe this is the setup that has
the most support:
RuntimeException
^
|
CascadingRuntimeException // new
^
|-- StartException // new
|
|-- StopException // new
|
|-- SuspendException // new
|
\-- ResumeException // new
Exception
^
|
CascadingException
^
|-- ContextException <-- ContextualizationException // new; have both or
have one...which one?
|
|-- CompositionException // new
|
|-- ConfigurationException
|
\-- InitializationException // new
interface Startable { // better name, anyone?
void start() throws StartException;
void stop() throws StopException; // new
}
interface Suspendable { // better name, anyone?
void suspend() throws SuspendException;
void resume() throws ResumeException; // new
}
abstract class ClassImplementingAllLifecycleMethods implements
Loggable
Contexualizable,
Composable, // name change
Configurable
Initializable
Startable
Runnable
Suspendable
Recontextualizable
Recomposable
Reconfigurable
Disposable
{
void setLogger( Logger logger ); // does this need a different name?
void contexualize( Context context ) throws ContextualizationException;
void compose( ComponentManager cm ) throws CompositionException;
void configure( Configuraion conf ) throws ConfigurationException;
void initialize() throws InitializationException; // name change
void start(); // might throw exception
void run(); // doesn't throw exception
void suspend(); // might throw exception
void recontextualize( Context context ) throws ContextualizationException;
void recompose( ComponentManager cm ) throws CompositionException;
void reconfigure( Configuration conf ) throws ConfigurationException;
void resume(); // might throw exception
void stop(); // might throw exception
void dispose(); // doesn't throw exception
}
any other suggestions/ -1s?
cheers,
LSD, who is now sure nobody on this list cares about versioning
so will start bugging said list about it when neccessary
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Peter Donald <do...@apache.org>.
At 09:39 10/4/01 -0400, Berin Loritsch wrote:
>> >init() throws InitializationException
>>
>> how about initialize() throws InitializationException ? ;)
>
>:) I know you proposed this before. Our previous decision
>was to keep it init() because of the familiarity of it. However,
>looking at the grammatical patterns of Avalon, it would be more
>consistent to use initialize().
>
>You have my +1 for initialize() if for no other reason than
>consistency of the API.
wow - dogged persistency pays off ... the fifth time I prospose it looks
like it could get through ;)
>What constitutes a RuntimeException in your mind? For things
>that MUST succeed or fail hard, we need explicit exceptions. That
>would include Contextualizable, Disposable, Initializable,
>Composer (Composable?).
I like Composable ... anyone else ??
>BTW, I propose that we merge Suspendable and Resumable. It doesn't
>make sence to have one without the other. All that means is that
>the interfaces do not declare explicit classes, but may throw Runtime
>Exceptions.
kewl - what name do you propose?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> At 10:11 10/4/01 +0200, Leo Simons wrote:
> >proposal:
> >For 4.0 of the framework code, CascadingException
> >is updated to extend RuntimeException,
>
> -1
>
> Whats wrong with CascadingRuntimeException???
True that. My previous +1 was for the concept.
+1 CascadingRuntimeException for lifecycle exceptions.
> >and new exceptions
> >are created for all lifecycle methods except run(), stop()
> >and dispose().
>
> -1 for run
> +1 for stop/start/resume/suspend/etc
> +/-0 for dispose() (it will be ignored anyway)
I agree.
-1 for run (We can't change Runnable's interface).
+1 for stop/start/resume/suspend
-1 for dispose (What would that accomplish? dispose is used
to clean up a Component so that the GarbageCollector will
get rid of it)
> >So:
> >contextualize() throws ContextualizationException
>
> How about ContextException?
It depends on it's use. If the ContextException comes from
a Context.get() call and passed up out of the method, then
+1 for ContextException. If it is derived only from the
contextualize() method, then we should use ContextualizationException.
I vote for ContextException +1. Use it to propogate
exceptions from the Context object.
> >init() throws InitializationException
>
> how about initialize() throws InitializationException ? ;)
:) I know you proposed this before. Our previous decision
was to keep it init() because of the familiarity of it. However,
looking at the grammatical patterns of Avalon, it would be more
consistent to use initialize().
You have my +1 for initialize() if for no other reason than
consistency of the API. (NOTE: a grammatical pattern in a
programming language is more analagous to a language idiom).
> >For:
> >- making use of RuntimeException means that existing code
> > will be able to compile and run if the exceptions are
> > not actually thrown.
>
> Short term benefit is not worth the long term negative effects IMO
What constitutes a RuntimeException in your mind? For things
that MUST succeed or fail hard, we need explicit exceptions. That
would include Contextualizable, Disposable, Initializable,
Composer (Composable?).
For things that have more runtime meaning, we should use Runtime
Exceptions. That would include Runnable, Stoppable, Suspendable,
Resumable.
BTW, I propose that we merge Suspendable and Resumable. It doesn't
make sence to have one without the other. All that means is that
the interfaces do not declare explicit classes, but may throw Runtime
Exceptions.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [vote] lifecycle exceptions
Posted by Peter Donald <do...@apache.org>.
At 10:11 10/4/01 +0200, Leo Simons wrote:
>proposal:
>For 4.0 of the framework code, CascadingException
>is updated to extend RuntimeException,
-1
Whats wrong with CascadingRuntimeException???
>and new exceptions
>are created for all lifecycle methods except run(), stop()
>and dispose().
-1 for run
+1 for stop/start/resume/suspend/etc
+/-0 for dispose() (it will be ignored anyway)
>
>So:
>contextualize() throws ContextualizationException
How about ContextException?
>init() throws InitializationException
how about initialize() throws InitializationException ? ;)
>For:
>- making use of RuntimeException means that existing code
> will be able to compile and run if the exceptions are
> not actually thrown.
Short term benefit is not worth the long term negative effects IMO
>- since the lifecycle exceptions are indeed (almost
> always) runtime exceptions, this setup is also
> correct.
What makes you so sure. I have gone out of my way to make all lifecycle
exceptions not RuntimeExceptions ;)
>- does Cocoon2 have the time to update to this before the
> beta? (if not, I propose the same change for 4.1)
Should have.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [vote] lifecycle exceptions
Posted by Stephen McConnell <mc...@osm.net>.
> -----Original Message-----
> From: Leo Simons [mailto:mail@leosimons.com]
> Sent: Tuesday, 10 April, 2001 10:11
> To: Avalon Development
> Subject: [vote] lifecycle exceptions
>
>
> proposal:
> For 4.0 of the framework code, CascadingException
> is updated to extend RuntimeException,
-1 on this extending RuntimeException
we are in alpha - i.e. now is the time to make the change
> and new exceptions
> are created for all lifecycle methods except run(), stop()
> and dispose().
+1
> So:
> contextualize() throws ContextualizationException
+1
> init() throws InitializationException
+1, but prefer initilize() throws InitializationException
> etc.
>
> For:
> - existing code has already proven the exceptions are
> neccessary. We need to add them.
> - making use of RuntimeException means that existing code
> will be able to compile and run if the exceptions are
> not actually thrown.
true but my feeling is that this only pushes the problem out into the future
when the impact of change will be higher
> - since the lifecycle exceptions are indeed (almost
> always) runtime exceptions, this setup is also
> correct.
but this ignores the fact that runtime exceptions do not need to be declared
or exclicity caught at build time
> Against:
> - a significant body of existing code that uses avalon will
> have to be updated to work with the new release (OTOH, it
> will be a lot more work to change this later).
this is my feeling to, now is the time to change it
> - does Cocoon2 have the time to update to this before the
> beta? (if not, I propose the same change for 4.1)
>
> cheers!
>
> LSD
Steve.
> <java:sig>
> About LSD = new PersonalInfo();
> LSD.name("Leo Simons");
> LSD.email("mail@leosimons.com");
> LSD.URL( [
> http://www.leosimons.com, // personal website
> http://www.atfantasy.com, // fantasy RPG portal
> http://www.the-sign.nl // web-design company
> ] );
> LSD.quote("Buh!");
> email.setSig((String)LSD);
> </java:sig>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org