You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/08/17 21:53:30 UTC
1st test with ExcaliburTestCase and our Monitors
The tests pass with flying colors. It turns out that the PropertyChangeListeners
need to be given some time to operate--and they can run outside the current thread.
We have two monitors:
The ActiveMonitor and the PassiveMonitor.
The ActiveMonitor polls the Resource every X milliseconds
(specified by the "frequency" element). If the resource
has changed then the "last-modified" time changes. This
allows you to monitor resources that might be altered by
third parties.
The PassiveMonitor does nothing except manage the Resources
in the same manner that all Monitors manage resources.
All Resources have the responsibility to notify all listeners
if it has been modified through the Resource class. As both
an example and a practical example, the StreamResource is used
by all classes that manage the contents by IO streams. When
a writing IO stream (obtained from the StreamResource) closes,
the StreamResource notifies all of its listeners.
It works pretty well!
The we can have an implementation of the Cache that is notified
by the Monitor section.
Also, you can test your own Monitors by adding a simple test
script to get the Monitor in question.
We might want to set up the ExcaliburTestCase so that the
initialize() and dispose() methods are called only once during
the life of the test. In order to do that, we have to use a
TestDecorator that performs that action.
JUnit calls setUp() and tearDown() around each testXXXX() method.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: 1st test with ExcaliburTestCase and our Monitors
Posted by Berin Loritsch <bl...@apache.org>.
One logical/conceptual error. I went too far with the JavaBean
approach,
and assumed that we had one listener per resource. One of the planned
uses
was to have one listener (i.e. a cache, a program generator, etc.) for
a larger number of resources. I have changed the name of the property
returned by the PropertyChangeEvent to be the value returned by the
getResourceKey() method.
Berin Loritsch wrote:
>
> The tests pass with flying colors. It turns out that the PropertyChangeListeners
> need to be given some time to operate--and they can run outside the current thread.
>
> We have two monitors:
>
> The ActiveMonitor and the PassiveMonitor.
>
> The ActiveMonitor polls the Resource every X milliseconds
> (specified by the "frequency" element). If the resource
> has changed then the "last-modified" time changes. This
> allows you to monitor resources that might be altered by
> third parties.
>
> The PassiveMonitor does nothing except manage the Resources
> in the same manner that all Monitors manage resources.
>
> All Resources have the responsibility to notify all listeners
> if it has been modified through the Resource class. As both
> an example and a practical example, the StreamResource is used
> by all classes that manage the contents by IO streams. When
> a writing IO stream (obtained from the StreamResource) closes,
> the StreamResource notifies all of its listeners.
>
> It works pretty well!
>
> The we can have an implementation of the Cache that is notified
> by the Monitor section.
>
> Also, you can test your own Monitors by adding a simple test
> script to get the Monitor in question.
>
> We might want to set up the ExcaliburTestCase so that the
> initialize() and dispose() methods are called only once during
> the life of the test. In order to do that, we have to use a
> TestDecorator that performs that action.
>
> JUnit calls setUp() and tearDown() around each testXXXX() method.
>
> ---------------------------------------------------------------------
> 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: 1st test with ExcaliburTestCase and our Monitors
Posted by giacomo <gi...@apache.org>.
On Fri, 17 Aug 2001, Berin Loritsch wrote:
> The tests pass with flying colors. It turns out that the PropertyChangeListeners
> need to be given some time to operate--and they can run outside the current thread.
>
> We have two monitors:
>
> The ActiveMonitor and the PassiveMonitor.
>
> The ActiveMonitor polls the Resource every X milliseconds
> (specified by the "frequency" element). If the resource
> has changed then the "last-modified" time changes. This
> allows you to monitor resources that might be altered by
> third parties.
>
> The PassiveMonitor does nothing except manage the Resources
> in the same manner that all Monitors manage resources.
>
> All Resources have the responsibility to notify all listeners
> if it has been modified through the Resource class. As both
> an example and a practical example, the StreamResource is used
> by all classes that manage the contents by IO streams. When
> a writing IO stream (obtained from the StreamResource) closes,
> the StreamResource notifies all of its listeners.
>
> It works pretty well!
>
> The we can have an implementation of the Cache that is notified
> by the Monitor section.
>
> Also, you can test your own Monitors by adding a simple test
> script to get the Monitor in question.
>
> We might want to set up the ExcaliburTestCase so that the
> initialize() and dispose() methods are called only once during
> the life of the test. In order to do that, we have to use a
> TestDecorator that performs that action.
I've thought about that, too.
Giacomo
>
> JUnit calls setUp() and tearDown() around each testXXXX() method.
>
> ---------------------------------------------------------------------
> 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