You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/01/09 18:54:35 UTC
BlockListener needs more methods
Peter,
I think BlockListener needs :
void blockStarted( BlockEvent event );
void blockStopped( BlockEvent event );
void blockInitialized( BlockEvent event );
Thoughts?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Eung-ju Park <co...@apache.org>.
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Thursday, January 10, 2002 2:54 AM
Subject: BlockListener needs more methods
> Peter,
>
> I think BlockListener needs :
>
> void blockStarted( BlockEvent event );
> void blockStopped( BlockEvent event );
> void blockInitialized( BlockEvent event );
>
> Thoughts?
Notify event when all lifecycle event is so complicate.
I think it is not necessary...
Hmm... blockStarted and blockStopped is may be necessary for AltRMI
publisher.
unpublish when block stopped. republish when block started. But is other
event is necessary?
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>>I think BlockListener needs :
>>
>> void blockStarted( BlockEvent event );
>>
>
>you mean something different from blockAdded() ?
>
>> void blockStopped( BlockEvent event );
>>
>
>you mean something different from blockRemoved() ?
>
OK OK, I was confused!
What exists is fine... :-)
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Paul Hammant <Pa...@yahoo.com>.
Eung-ju,
>>A quick question..
>>
>>While looking through Eung-Ju's excellent RmiListener block it was
>>apparent that the blocks were blockAdded() in an expected order. That
>>is new to me and good news if true. Is it that they are added in the
>>same order as listed in assembly.xml ?
>>
>
>blockAdded event not same order as listed in assembly.xml.
>RMIficationListener not depend on order of blockAdded event. Just delaying
>events and process it when RMIfication is ready.
>
I see you code Eung-Ju, and have copied the class for altrmi, but it
does not feel good. Life as application writer should be made as easy
as possible. The queue logic you've written, though working, should not
have to be written (ideal world).
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Eung-ju Park <co...@apache.org>.
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Monday, January 14, 2002 5:16 PM
Subject: Re: BlockListener needs more methods
> Peter,
>
> A quick question..
>
> While looking through Eung-Ju's excellent RmiListener block it was
> apparent that the blocks were blockAdded() in an expected order. That
> is new to me and good news if true. Is it that they are added in the
> same order as listed in assembly.xml ?
blockAdded event not same order as listed in assembly.xml.
RMIficationListener not depend on order of blockAdded event. Just delaying
events and process it when RMIfication is ready.
>
> Regards,
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>So the block listener developer instantiates and throws back? I'd go for :
>>
>>ApplicationStartupException extended by VetoApplicationStartupException
>>(to please Stephen?).
>>
>
>Im not sure - seems like extra complexity that we don't need? Is there any
>going to be more than 1 type of exception?
>
OK. I am fond of trees of Exceptions. However this is not so much an
application as a framework, one will do.
>>>Not sure what do you think?
>>>
>>For the sake of backCompat, I;d say ApplicationListener extends
>>BlockListener then.
>>
>
>ok. Fine by me. It feels a bit icky technically but right because it is
>backwards compatible.
>
I'm quite happy with interface extension. If the JDBC team had done it
for JDBC3 then AvalonDB would not have been so screwed trying to be
fully compatible.....
We'd have assembly XML segments ...
<application-listener class="class" name="name" />
.... in additon to ....
<block-listener class="class" name="name" />
... to declare which is being used.
>I suppose in the future we could add an
>AbstractBlockListener and gradually migrate them to one interface (at same
>time we go from alpha to beta).
>
Perhaps, but it could stay as is. I'd prefer to get it right now,
despite pain rather than choose to migrate later. However, I'll never
force a policy for Phoenix development :-)
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Peter Donald <pe...@apache.org>.
On Tue, 15 Jan 2002 22:52, Paul Hammant wrote:
> >>
> >>BlockListener
> >>{
> >>// as before plus ....
> >> void applicationStarting();
> >
> >lets make this one capable of throwing an exception - maybe
> >ApplicationUnavailableException or UnavailableApplicationException or
> > maybe even a vanilla Exception.
>
> So the block listener developer instantiates and throws back? I'd go for :
>
> ApplicationStartupException extended by VetoApplicationStartupException
> (to please Stephen?).
Im not sure - seems like extra complexity that we don't need? Is there any
going to be more than 1 type of exception?
> >>Question, should these new methods go in an interface called
> >>ApplicationListener that extends BlockListener or not?
> >
> >not sure - that was something I was going to try out. I wanted to because
> > I really really don't want to break backwards compatability prior to
> > going beta however I am not sure if it is a good idea.
> >
> >Not sure what do you think?
>
> For the sake of backCompat, I;d say ApplicationListener extends
> BlockListener then.
ok. Fine by me. It feels a bit icky technically but right because it is
backwards compatible. I suppose in the future we could add an
AbstractBlockListener and gradually migrate them to one interface (at same
time we go from alpha to beta).
> Lastly, and unrelated. I'm (as you know) using Mozilla. Its inline
> replies are apparently no so nice. Is the "double CR" like I'm using in
> this reply better for you textmode readers? You using pine?
no idea - I use KMail (from KDE desktop) and it handles most things well. (It
is like Eudora of 1 revision ago if that helps).
--
Cheers,
Pete
--------------------------------
My opinions may have changed,
but not the fact that I am right
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>ApplicationEvent
>>{
>> SarMetaData getSarMetaData();
>>}
>>
>>BlockListener
>>{
>>// as before plus ....
>> void applicationStarting();
>>
>
>lets make this one capable of throwing an exception - maybe
>ApplicationUnavailableException or UnavailableApplicationException or maybe
>even a vanilla Exception.
>
So the block listener developer instantiates and throws back? I'd go for :
ApplicationStartupException extended by VetoApplicationStartupException
(to please Stephen?).
>>Question, should these new methods go in an interface called
>>ApplicationListener that extends BlockListener or not?
>>
>
>not sure - that was something I was going to try out. I wanted to because I
>really really don't want to break backwards compatability prior to going beta
>however I am not sure if it is a good idea.
>
>Not sure what do you think?
>
For the sake of backCompat, I;d say ApplicationListener extends
BlockListener then.
Lastly, and unrelated. I'm (as you know) using Mozilla. Its inline
replies are apparently no so nice. Is the "double CR" like I'm using in
this reply better for you textmode readers? You using pine?
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: BlockListener needs more methods
Posted by Stephen McConnell <mc...@osm.net>.
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Tuesday, 15 January, 2002 11:37
> To: Avalon Developers List
> Subject: Re: BlockListener needs more methods
>
>
> On Tue, 15 Jan 2002 20:46, Paul Hammant wrote:
> > >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();
>
> lets make this one capable of throwing an exception - maybe
> ApplicationUnavailableException or
> UnavailableApplicationException or maybe
> even a vanilla Exception.
+1
java.lang.Exception seems most appropriate to me.
> > 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?
>
> not sure - that was something I was going to try out. I wanted to
> because I really really don't want to break backwards compatability prior
> to going beta however I am not sure if it is a good idea.
I don't see any benefit. If I want a listener just to listen to
application rising then all I need is an ApplicationListener. If
my application listener is also a block listener (option) then I would
implement both interfaces. I presuming here that the application
listener laucher would check an application listener for implementation
of the block listener interface a auto-register the app listener as a
block listener.
Steve.
> Not sure what do you think?
>
> --
> Cheers,
>
> Pete
>
> "The perfect way is only difficult for those who pick and choose. Do not
> like, do not dislike; all will then be clear. Make a hairbreadth
> difference and heaven and earth are set apart; if you want the truth to
> stand clear before you, never be for or against." - Bruce Lee
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Peter Donald <pe...@apache.org>.
On Tue, 15 Jan 2002 20:46, Paul Hammant wrote:
> >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();
lets make this one capable of throwing an exception - maybe
ApplicationUnavailableException or UnavailableApplicationException or maybe
even a vanilla Exception.
> 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?
not sure - that was something I was going to try out. I wanted to because I
really really don't want to break backwards compatability prior to going beta
however I am not sure if it is a good idea.
Not sure what do you think?
--
Cheers,
Pete
"The perfect way is only difficult for those who pick and choose. Do not
like, do not dislike; all will then be clear. Make a hairbreadth
difference and heaven and earth are set apart; if you want the truth to
stand clear before you, never be for or against." - Bruce Lee
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: BlockListener needs more methods
Posted by Stephen McConnell <mc...@osm.net>.
Paul:
Actually, I'm kind of coming around to ApplicationListener
extends BlockListener. Will probably keep things simpler.
Steve.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Tuesday, 15 January, 2002 15:19
> To: Avalon Developers List
> Subject: Re: BlockListener needs more methods
>
>
> Stephen,
>
> >Paul:
> >
> >I would have placed these methods in an ApplicationListener interface
> >that is independent of BlockListener.
> >
> > ApplicationListener
> > {
> > void applicationStarting();
> > void applicationStarted(ApplicationEvent applicationEvent);
> > void applicationStopping();
> > void applicationStopped();
> > void applicationFailure(Exception causeOfFailure);
> > }
> >
>
> Could do. I need something that is both a block and app listener
> through. As long as we have this concept.- >
>
> class MyAppBlockListener implements BlockListener, AppListener {
> }
>
> <appNblock-listener class="class" name="name" />
>
> Regards,
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>Paul:
>
>I would have placed these methods in an ApplicationListener interface
>that is independent of BlockListener.
>
> ApplicationListener
> {
> void applicationStarting();
> void applicationStarted(ApplicationEvent applicationEvent);
> void applicationStopping();
> void applicationStopped();
> void applicationFailure(Exception causeOfFailure);
> }
>
Could do. I need something that is both a block and app listener
through. As long as we have this concept.- >
class MyAppBlockListener implements BlockListener, AppListener {
}
<appNblock-listener class="class" name="name" />
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>On Thu, 17 Jan 2002 00:53, Paul Hammant wrote:
>
>>Draft interfaces booked into Phoenix CVS for your approval....
>>For actual changes I'll check the diffs with you, but interfaces are
>>harmless as 'add/commits' right?
>>
>
>just check it in :)
>
Done, thats what I meant when I said booked in. The whole RCS/VCS
industry has coined too many terms for teh same thing.....
- Paul
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Peter Donald <pe...@apache.org>.
On Thu, 17 Jan 2002 00:53, Paul Hammant wrote:
> Draft interfaces booked into Phoenix CVS for your approval....
> For actual changes I'll check the diffs with you, but interfaces are
> harmless as 'add/commits' right?
just check it in :)
--
Cheers,
Pete
Duct tape is like the force. It has a light side, and a dark side, and
it binds the universe together ...
-- Carl Zwanzig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter, Stephen,
Draft interfaces booked into Phoenix CVS for your approval....
For actual changes I'll check the diffs with you, but interfaces are
harmless as 'add/commits' right?
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Peter Donald <pe...@apache.org>.
On Wed, 16 Jan 2002 01:01, Stephen McConnell wrote:
> Paul:
>
> I would have placed these methods in an ApplicationListener interface
> that is independent of BlockListener.
>
> ApplicationListener
> {
> void applicationStarting();
> void applicationStarted(ApplicationEvent applicationEvent);
> void applicationStopping();
> void applicationStopped();
> void applicationFailure(Exception causeOfFailure);
> }
>
> BTW, Pete, what's the reason for ApplicationEvent appearing in
> applicationStarted as opposed to applicationStarting ? I think
> that the application event should be provided as early as possible.
good point. I stuffed up :) It should be in starting()
--
Cheers,
Pete
*------------------------------------------------*
| You can't wake a person who is pretending |
| to be asleep. -Navajo Proverb. |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: BlockListener needs more methods
Posted by Stephen McConnell <mc...@osm.net>.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Tuesday, 15 January, 2002 10:46
> To: Avalon Developers List
> Subject: Re: BlockListener needs more methods
>
>
> 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?
Paul:
I would have placed these methods in an ApplicationListener interface
that is independent of BlockListener.
ApplicationListener
{
void applicationStarting();
void applicationStarted(ApplicationEvent applicationEvent);
void applicationStopping();
void applicationStopped();
void applicationFailure(Exception causeOfFailure);
}
BTW, Pete, what's the reason for ApplicationEvent appearing in
applicationStarted as opposed to applicationStarting ? I think
that the application event should be provided as early as possible.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Paul Hammant <Pa...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Peter Donald <pe...@apache.org>.
On Mon, 14 Jan 2002 22:32, Paul Hammant wrote:
> Peter,
>
> >>In which case dude, could we have a startupCompleted() or blocksAdded()
> >>or initialBlocksAdded(). This will help having cleaner code in
> >>blockAdded() The buffering of things that can;t be used yet is *very*
> >>cumbersome.
> >
> >Yep - on my todo list ;) I need to try a few things to see which is the
> >easiest and cleanest way to do things.
>
> 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.
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.
> I see you are quite busy on Ant
yep - will be for a bit too ;)
> and a possible
> forthcoming Logger flame war on commons :-) Incidentally, perhaps I
> should have spotted that last and intervened earlier.
nah I am done with that. Let there be 10 versions of each object at Jakarta I
say ;)
--
Cheers,
Pete
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>In which case dude, could we have a startupCompleted() or blocksAdded()
>>or initialBlocksAdded(). This will help having cleaner code in
>>blockAdded() The buffering of things that can;t be used yet is *very*
>>cumbersome.
>>
>
>Yep - on my todo list ;) I need to try a few things to see which is the
>easiest and cleanest way to do things.
>
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). I see you are quite busy on Ant and a possible
forthcoming Logger flame war on commons :-) Incidentally, perhaps I
should have spotted that last and intervened earlier.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Peter Donald <pe...@apache.org>.
On Mon, 14 Jan 2002 22:10, Paul Hammant wrote:
> In which case dude, could we have a startupCompleted() or blocksAdded()
> or initialBlocksAdded(). This will help having cleaner code in
> blockAdded() The buffering of things that can;t be used yet is *very*
> cumbersome.
Yep - on my todo list ;) I need to try a few things to see which is the
easiest and cleanest way to do things.
--
Cheers,
Pete
--------------------------------------------------
you've made a dangerous leap right over common
sense, like some kind of metaphysical Evil Knievel
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>While looking through Eung-Ju's excellent RmiListener block it was
>>apparent that the blocks were blockAdded() in an expected order. That
>>is new to me and good news if true. Is it that they are added in the
>>same order as listed in assembly.xml ?
>>
>
>No ;)
>
>The blocks are loaded accorind to their dependencies. So if Block A depends
>on Block B then B will be loaded before A (and shutdown before A). It is
>probably the case that it will be in order defined in assembly.xml excluding
>dependencies - however this should not be relied upon because it may change
>in the future ;) (Well probably not but you shouldn't be relying on it
>anyways).
>
In which case dude, could we have a startupCompleted() or blocksAdded()
or initialBlocksAdded(). This will help having cleaner code in
blockAdded() The buffering of things that can;t be used yet is *very*
cumbersome.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Peter Donald <pe...@apache.org>.
On Mon, 14 Jan 2002 19:16, Paul Hammant wrote:
> While looking through Eung-Ju's excellent RmiListener block it was
> apparent that the blocks were blockAdded() in an expected order. That
> is new to me and good news if true. Is it that they are added in the
> same order as listed in assembly.xml ?
No ;)
The blocks are loaded accorind to their dependencies. So if Block A depends
on Block B then B will be loaded before A (and shutdown before A). It is
probably the case that it will be in order defined in assembly.xml excluding
dependencies - however this should not be relied upon because it may change
in the future ;) (Well probably not but you shouldn't be relying on it
anyways).
--
Cheers,
Pete
--------------------------------
My opinions may have changed,
but not the fact that I am right
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: BlockListener needs more methods
Posted by Stephen McConnell <mc...@osm.net>.
The order in assembly.xml establishes the initial
order prior to dependency reshuffling. If there are
no block dependencies then the order will be the
same as assembly.xml order, otherwise the order gets
rearranged so that non-dependent blocks get loaded
before dependent blocks.
Steve.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Monday, 14 January, 2002 09:17
> To: Avalon Developers List
> Subject: Re: BlockListener needs more methods
>
>
> Peter,
>
> A quick question..
>
> While looking through Eung-Ju's excellent RmiListener block it was
> apparent that the blocks were blockAdded() in an expected order. That
> is new to me and good news if true. Is it that they are added in the
> same order as listed in assembly.xml ?
>
> Regards,
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
A quick question..
While looking through Eung-Ju's excellent RmiListener block it was
apparent that the blocks were blockAdded() in an expected order. That
is new to me and good news if true. Is it that they are added in the
same order as listed in assembly.xml ?
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Peter Donald <pe...@apache.org>.
Listeners can now receive Loggers. I will look into exposing the other events
and their parameters a bit later on - maybe Monday night. If I forget - prod
me ;)
On Thu, 10 Jan 2002 22:19, Stephen McConnell wrote:
> Peter Donald wrote:
> [on BlockListener]
>
> > Stephen do you recall when that was or have a pointer into the archives ?
>
> Pete:
>
> Here is your email to me which I have not yet replied to.
> (I was swamped by external events at the time and need to get
> my head back around this stuff - but not right now - other things
> that I have to deal with just at the moment).
>
> Steve.
>
> =====================================================================
>
> > -----Original Message-----
> > From: Peter Donald [mailto:donaldp@apache.org]
> > Sent: Sunday, 18 November, 2001 02:23
> > To: Avalon Developers List
> > Subject: Re: BlockListener and LifecycleHelper
> >
> > On Sun, 18 Nov 2001 00:27, Stephen McConnell wrote:
> > > Peter Donald wrote:
> > > > On Sat, 17 Nov 2001 00:16, Stephen McConnell wrote:
> > > > > I want LifecycleHelper to invoke component lifecycle phases
> > > > > on a listener.
> > > >
> > > > right. I don't mind LogEnabled but I don't like any of the others ;)
> > > >
> > > > > You objected to this because you said that
> > > > > listener logic should reside in a block.
> > > >
> > > > I said there was no such thing as listener logic. Listeners are
> > > > just glue to stick together blocks appropriately ;)
> > >
> > > And I said that happended to by your use-case, not mine :-)
> >
> > Right but the functionality you want to implement is already
> > supported. My
> > use-case was designed for application wide aspects / policy /
> > facilities /
> > whatever. So far you have yet to say where this model breaks down in your
> > case. You just said it does. I need facts not opinions ;)
> >
> > So what is missing from the model I propose that would;
> > * degrade quality of implementation/design
> > * make it impossible to implement some functionality
> > etc
> >
> > The only thing I have considered is maybe that not enough events are
> > supported. It may be useful to support other events such as
> >
> > 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
> >
> > It is possible that the above may be useful to add ... not sure aty this
> > stage. (or at minimum the appStarted + appStopping)
> >
> > > > coposition can't be done as there is no notion of dependencies.
> > > > initialization shouldn't really be done as no listener should be
> > > > allocating any significant resources (same reason for KB'ing
> > > > dispose)
> > >
> > > Agree - I should not have included compose (my mistake). Let me
> > > outline the "component" interface that I want to see support
> > > for and the reasons why:
> > >
> > > LogEnabled - If I'm logging anything within an object that's
> > > declared as a listener, I don't want to have to set-up
> > > another logger - just want to be supplied automagically
> >
> > reasonable.
> >
> > > Contextualizable - this one is a little tricky - the code
> > > I have is doing validation of the environment before blocks
> > > kick in - validation needs the information about the
> > > application context (available under the application meta-data
> > > receivable under contextualization of a listener).
> >
> > hmmm - is this a local modification? The only thing you can get from
> > BlockContext as far as I see is the Application name and application dir.
> > Have you modified it locally to get other stuff?
>
> [yep - its a local modification - sorry about that]
>
> > > To veto
> > > start-up, I need to be in application space (no block space)
> > > because I can throw an exception and halt/suspend start-up.
> >
> > Would adding notification of the events mentioned above work for this?
> >
> > > Initializable - Because I'm following Avalon component
> > > pattern and this is the trigger to start working and I don't
> > > like changing that without having some tangible
> > > justification.
> >
> > I need to know what "work" you are doing before I can judge whether it is
> > something we want to support ;)
> >
> > > > > I need to understand why your objecting to that.
> > > >
> > > > Put it this way. I see listeners as not doing any logic - they are
> > > > declarative constructs for establishing relationships. I want
> >
> > to know why
> >
> > > > this will not work in your case.
> > >
> > > 1. because I am NOT wiring blocks together
> > > 2. because I don't have an alternative mechanism
> > > 3. because I object to assertion that the current listener declaration
> > > is a valid "declarative constructs for establishing relationships"
> > > (it only references a class name within the scope of the application
> > > and declares nothing about relationships)
> > > 4. because I'm dealing with application policy
> > > 5. because I'm stubborn and you haven't given me a good tangible
> > > technical argument why this is inappropriate
> > > 6. because I wanted to have a least six bullet points
> >
> > ;P
> >
> > > > So far you have only indicated that you
> > > > "want" to do logic in listeners. I want to know why the listeners as
> > > > declaratives model doesn't work in your case or makes it harder
> > > > to construct your application. So far I haven't seen any
> >
> > indication that
> >
> > > > this is so ;)
> > >
> > > I'm handling application level policy. The registration of a listener
> > > is the only access point I have to plug-in an application-level
> >
> > facility.
> >
> > right.
> >
> > > This
> > > is a different use-case to yours - but that does not make it
> >
> > invalid - just
> >
> > > different. All I'm proposing is that IF a class, registered as
> >
> > a listener,
> >
> > > exposes any of the above component interfaces, then, give the
> >
> > class what it
> >
> > > needs to do its stuff correctly.
> >
> > You still haven't really told me exactly what you want to do and why the
> > current model doesn't work for you. If LogEnabled was supported and some
> > extra events were added (like above) would you be able to
> > implement what you
> > want to implement?
> >
> > --
> > Cheers,
> >
> > Pete
--
Cheers,
Pete
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Peter Donald <pe...@apache.org>.
On Thu, 10 Jan 2002 22:55, Stephen McConnell wrote:
> > > Here is your email to me which I have not yet replied to.
> > > (I was swamped by external events at the time and need to get
> > > my head back around this stuff - but not right now - other things
> > > that I have to deal with just at the moment).
kool.
> > However, ....
> > 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.
It will definetly be possible to pass in the meta-info or something similar
and definetly possible to veto startup.
I am less sure about application shutdown and very hesitent to do phoenix
shutdown. One thing I did implement a while ago was that by default if
phoenix contains no active applications (or none being loaded) then it would
shutdown unless a --keep-alive was passed in via command line.
So if I could find a decent mechanism for shutdown of the application it may
be possible to satisfy your needs thusly. I may go have a look at some of
the other similar app kernels and see how they do it.
> And one more little feature - I want to be able to pass an
> argument on the command line when starting Phoenix and have that
> argument passed onto my application listener (but without modifying
> code - i.e. the command line arg could be something like:
>
> -listener net.osm.WayCoolAppListener "wishlist,true"
>
> (Just my little wish list :-) )
This is an interesting question. Most of the J2EE infrastructure (and
friends) require that all "parameters" be specified in some sort of
descriptor or config file. However the desire for this popped up in a few
places and in a JSR I was on. So maybe it would be possible. However in this
case I think the way that it would be done would be to be able to overide
variables that are specified in the config file already.
Anyways that will probably be lower priorty than the BlockListener stuff
--
Cheers,
Pete
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: BlockListener needs more methods
Posted by Stephen McConnell <mc...@osm.net>.
I wrote:
> > Sent: Thursday, 10 January, 2002 12:20
> > To: Avalon Developers List
> > Subject: RE: BlockListener needs more methods
> >
> >
> >
> > Peter Donald wrote:
> > [on BlockListener]
> > > Stephen do you recall when that was or have a pointer into the
> > archives ?
> >
> > Pete:
> >
> > Here is your email to me which I have not yet replied to.
> > (I was swamped by external events at the time and need to get
> > my head back around this stuff - but not right now - other things
> > that I have to deal with just at the moment).
>
> However, ....
> 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.
And one more little feature - I want to be able to pass an
argument on the command line when starting Phoenix and have that
argument passed onto my application listener (but without modifying
code - i.e. the command line arg could be something like:
-listener net.osm.WayCoolAppListener "wishlist,true"
(Just my little wish list :-) )
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: BlockListener needs more methods
Posted by Stephen McConnell <mc...@osm.net>.
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@osm.net]
> Sent: Thursday, 10 January, 2002 12:20
> To: Avalon Developers List
> Subject: RE: BlockListener needs more methods
>
>
>
> Peter Donald wrote:
> [on BlockListener]
> > Stephen do you recall when that was or have a pointer into the
> archives ?
>
> Pete:
>
> Here is your email to me which I have not yet replied to.
> (I was swamped by external events at the time and need to get
> my head back around this stuff - but not right now - other things
> that I have to deal with just at the moment).
However, ....
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.
Cheers, Steve.
> Steve.
>
> =====================================================================
>
>
> > -----Original Message-----
> > From: Peter Donald [mailto:donaldp@apache.org]
> > Sent: Sunday, 18 November, 2001 02:23
> > To: Avalon Developers List
> > Subject: Re: BlockListener and LifecycleHelper
> >
> >
> > On Sun, 18 Nov 2001 00:27, Stephen McConnell wrote:
> > > Peter Donald wrote:
> > > > On Sat, 17 Nov 2001 00:16, Stephen McConnell wrote:
> > > > > I want LifecycleHelper to invoke component lifecycle phases
> > > > > on a listener.
> > > >
> > > > right. I don't mind LogEnabled but I don't like any of the others ;)
> > > >
> > > > > You objected to this because you said that
> > > > > listener logic should reside in a block.
> > > >
> > > > I said there was no such thing as listener logic. Listeners are
> > > > just glue to stick together blocks appropriately ;)
> > >
> > > And I said that happended to by your use-case, not mine :-)
> >
> > Right but the functionality you want to implement is already
> > supported. My
> > use-case was designed for application wide aspects / policy /
> > facilities /
> > whatever. So far you have yet to say where this model breaks
> down in your
> > case. You just said it does. I need facts not opinions ;)
> >
> > So what is missing from the model I propose that would;
> > * degrade quality of implementation/design
> > * make it impossible to implement some functionality
> > etc
> >
> > The only thing I have considered is maybe that not enough events are
> > supported. It may be useful to support other events such as
> >
> > 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
> >
> > It is possible that the above may be useful to add ... not sure aty this
> > stage. (or at minimum the appStarted + appStopping)
> >
> > > > coposition can't be done as there is no notion of dependencies.
> > > > initialization shouldn't really be done as no listener should be
> > > > allocating any significant resources (same reason for KB'ing
> > > > dispose)
> > >
> > > Agree - I should not have included compose (my mistake). Let me
> > > outline the "component" interface that I want to see support
> > > for and the reasons why:
> > >
> > > LogEnabled - If I'm logging anything within an object that's
> > > declared as a listener, I don't want to have to set-up
> > > another logger - just want to be supplied automagically
> >
> > reasonable.
> >
> > > Contextualizable - this one is a little tricky - the code
> > > I have is doing validation of the environment before blocks
> > > kick in - validation needs the information about the
> > > application context (available under the application meta-data
> > > receivable under contextualization of a listener).
> >
> > hmmm - is this a local modification? The only thing you can get from
> > BlockContext as far as I see is the Application name and
> application dir.
> > Have you modified it locally to get other stuff?
>
> [yep - its a local modification - sorry about that]
>
> > > To veto
> > > start-up, I need to be in application space (no block space)
> > > because I can throw an exception and halt/suspend start-up.
> >
> > Would adding notification of the events mentioned above work for this?
> >
> > > Initializable - Because I'm following Avalon component
> > > pattern and this is the trigger to start working and I don't
> > > like changing that without having some tangible
> > > justification.
> >
> > I need to know what "work" you are doing before I can judge
> whether it is
> > something we want to support ;)
> >
> > > > > I need to understand why your objecting to that.
> > > >
> > > > Put it this way. I see listeners as not doing any logic - they are
> > > > declarative constructs for establishing relationships. I want
> > to know why
> > > > this will not work in your case.
> > >
> > > 1. because I am NOT wiring blocks together
> > > 2. because I don't have an alternative mechanism
> > > 3. because I object to assertion that the current listener declaration
> > > is a valid "declarative constructs for establishing relationships"
> > > (it only references a class name within the scope of the
> application
> > > and declares nothing about relationships)
> > > 4. because I'm dealing with application policy
> > > 5. because I'm stubborn and you haven't given me a good tangible
> > > technical argument why this is inappropriate
> > > 6. because I wanted to have a least six bullet points
> >
> > ;P
> >
> > > > So far you have only indicated that you
> > > > "want" to do logic in listeners. I want to know why the listeners as
> > > > declaratives model doesn't work in your case or makes it harder
> > > > to construct your application. So far I haven't seen any
> > indication that
> > > > this is so ;)
> > >
> > > I'm handling application level policy. The registration of a listener
> > > is the only access point I have to plug-in an application-level
> > facility.
> >
> > right.
> >
> > > This
> > > is a different use-case to yours - but that does not make it
> > invalid - just
> > > different. All I'm proposing is that IF a class, registered as
> > a listener,
> > > exposes any of the above component interfaces, then, give the
> > class what it
> > > needs to do its stuff correctly.
> >
> > You still haven't really told me exactly what you want to do and why the
> > current model doesn't work for you. If LogEnabled was supported and some
> > extra events were added (like above) would you be able to
> > implement what you
> > want to implement?
> >
> > --
> > Cheers,
> >
> > Pete
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: BlockListener needs more methods
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
[on BlockListener]
> Stephen do you recall when that was or have a pointer into the archives ?
Pete:
Here is your email to me which I have not yet replied to.
(I was swamped by external events at the time and need to get
my head back around this stuff - but not right now - other things
that I have to deal with just at the moment).
Steve.
=====================================================================
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Sunday, 18 November, 2001 02:23
> To: Avalon Developers List
> Subject: Re: BlockListener and LifecycleHelper
>
>
> On Sun, 18 Nov 2001 00:27, Stephen McConnell wrote:
> > Peter Donald wrote:
> > > On Sat, 17 Nov 2001 00:16, Stephen McConnell wrote:
> > > > I want LifecycleHelper to invoke component lifecycle phases
> > > > on a listener.
> > >
> > > right. I don't mind LogEnabled but I don't like any of the others ;)
> > >
> > > > You objected to this because you said that
> > > > listener logic should reside in a block.
> > >
> > > I said there was no such thing as listener logic. Listeners are
> > > just glue to stick together blocks appropriately ;)
> >
> > And I said that happended to by your use-case, not mine :-)
>
> Right but the functionality you want to implement is already
> supported. My
> use-case was designed for application wide aspects / policy /
> facilities /
> whatever. So far you have yet to say where this model breaks down in your
> case. You just said it does. I need facts not opinions ;)
>
> So what is missing from the model I propose that would;
> * degrade quality of implementation/design
> * make it impossible to implement some functionality
> etc
>
> The only thing I have considered is maybe that not enough events are
> supported. It may be useful to support other events such as
>
> 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
>
> It is possible that the above may be useful to add ... not sure aty this
> stage. (or at minimum the appStarted + appStopping)
>
> > > coposition can't be done as there is no notion of dependencies.
> > > initialization shouldn't really be done as no listener should be
> > > allocating any significant resources (same reason for KB'ing
> > > dispose)
> >
> > Agree - I should not have included compose (my mistake). Let me
> > outline the "component" interface that I want to see support
> > for and the reasons why:
> >
> > LogEnabled - If I'm logging anything within an object that's
> > declared as a listener, I don't want to have to set-up
> > another logger - just want to be supplied automagically
>
> reasonable.
>
> > Contextualizable - this one is a little tricky - the code
> > I have is doing validation of the environment before blocks
> > kick in - validation needs the information about the
> > application context (available under the application meta-data
> > receivable under contextualization of a listener).
>
> hmmm - is this a local modification? The only thing you can get from
> BlockContext as far as I see is the Application name and application dir.
> Have you modified it locally to get other stuff?
[yep - its a local modification - sorry about that]
> > To veto
> > start-up, I need to be in application space (no block space)
> > because I can throw an exception and halt/suspend start-up.
>
> Would adding notification of the events mentioned above work for this?
>
> > Initializable - Because I'm following Avalon component
> > pattern and this is the trigger to start working and I don't
> > like changing that without having some tangible
> > justification.
>
> I need to know what "work" you are doing before I can judge whether it is
> something we want to support ;)
>
> > > > I need to understand why your objecting to that.
> > >
> > > Put it this way. I see listeners as not doing any logic - they are
> > > declarative constructs for establishing relationships. I want
> to know why
> > > this will not work in your case.
> >
> > 1. because I am NOT wiring blocks together
> > 2. because I don't have an alternative mechanism
> > 3. because I object to assertion that the current listener declaration
> > is a valid "declarative constructs for establishing relationships"
> > (it only references a class name within the scope of the application
> > and declares nothing about relationships)
> > 4. because I'm dealing with application policy
> > 5. because I'm stubborn and you haven't given me a good tangible
> > technical argument why this is inappropriate
> > 6. because I wanted to have a least six bullet points
>
> ;P
>
> > > So far you have only indicated that you
> > > "want" to do logic in listeners. I want to know why the listeners as
> > > declaratives model doesn't work in your case or makes it harder
> > > to construct your application. So far I haven't seen any
> indication that
> > > this is so ;)
> >
> > I'm handling application level policy. The registration of a listener
> > is the only access point I have to plug-in an application-level
> facility.
>
> right.
>
> > This
> > is a different use-case to yours - but that does not make it
> invalid - just
> > different. All I'm proposing is that IF a class, registered as
> a listener,
> > exposes any of the above component interfaces, then, give the
> class what it
> > needs to do its stuff correctly.
>
> You still haven't really told me exactly what you want to do and why the
> current model doesn't work for you. If LogEnabled was supported and some
> extra events were added (like above) would you be able to
> implement what you
> want to implement?
>
> --
> Cheers,
>
> Pete
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockListener needs more methods
Posted by Peter Donald <pe...@apache.org>.
On Thu, 10 Jan 2002 04:54, Paul Hammant wrote:
> I think BlockListener needs :
>
> void blockStarted( BlockEvent event );
you mean something different from blockAdded() ?
> void blockStopped( BlockEvent event );
you mean something different from blockRemoved() ?
> void blockInitialized( BlockEvent event );
Im not sure why this is needed. I actually wrote to this a while ago about
some extra methods that could be added to the listener ... never got around
to it because no one expressed an opinion either way. Stephen do you recall
when that was or have a pointer into the archives ?
--
Cheers,
Pete
"The fact that a believer is happier than a skeptic is no more to the
point than the fact that a drunken man is happier than a sober one.
The happiness of credulity is a cheap and dangerous quality."
-- George Bernard Shaw
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>