Hello Leo!
AT> The thing is that I want to treat a missing config file just
AT> as a broken config file - I want it to have a validity, such
AT> that would become -1 as soon as file is created and that would
AT> stay +1 while the file is still missing.
LS> isn't this wat excalibur-monitor is for?
I beleive MissingValidity just complements the SourceValidity/Monitor
duet :-)
See how it works: currently monitor/SourceResource.java goes like
this:
public long lastModified()
{
if( null == m_validity )
{
return System.currentTimeMillis();
}
...
So, if we have a missing file the corresponding SourceObject
will always be considered invalid.
Imagine that we have the following application: as soon as
a config file changes a comples object built from this configuration
is re-constructed.
But, if the configuration file is missing, on every
PassiveMonitor.getResource() a new attempt to construct the complex
object will happen. It will fail soon, as the Source object will
fail to deliver an input stream, but on every request this will
go on and on again.
In contrast if source/impl/FileSource.java would return a MissingValidity
for a missing file the situation will be the following: on the
first request an attempt to construct the complex object will be
carried out. It will fail due to the lack of InputStream. But on the
second request the attempt _won't_ be carried out -- the file will
be considered _valid_ (although missing) -- in fact it is valid --
nothing has changed and we have already examined what we currently
have. _But_ once the file _is_ created on the next request the
Source object will be considered _invalid_ -- and it will be correct
as something has changed since the last time we have examined the
situation.
So, I beleive MissingValidity plubs super-smoothely into the
SourceValidity/Monitor framework :-)
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
