Gerhard Froehlich wrote:
>>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>>>For less-frequently used resources, wouldn't it be a better solution to
>>>only call getLastModified() when the resource is actually used and the
>>>time since the last call to getLastModified() is greater than the
>>>refresh period ? This would be a kind of buffering in front of the
>>>filesystem. Also, can't this be integrated directly in Source ?
>>>
>>
>>I would like to see Resource and Source merged. Or at the _very_ least,
>>Source extending Resource.
>>
>
> Where is the difference between Resource and Source in the Cocoon context?
In the end they represent the same thing: a file on the harddrive, a resource
from the classloader, etc.
The problem with classloaders is how do you know when they have changed?
You would have to make the assumption that they never change unless you can
get a File reference to the containing jar. In that case, you would be able
to test if that resource has been altered.
>>>Last point : your changes in ProgramGenerator make the assumption that
>>>sources are files. This won't be true in unexpanded war files and will
>>>very likely break the engine ;)
>>>
>>>What do you (and others) think ?
>>>
>>
>>There is room for more Resource types.
>>
>
> Ok, getting a little bit confused, now. Do you mean something like a
> MonitoredSource or something else. My first beginning was to implement
> the Resource Monitor direct into Source. But I didn't, cause I wanted
> to close to the problem domain slowly ;)(honestly it was more lack of
> knowledge).
I mean something like a ContextResource, ClassLoaderResource, URLResource.
The reason that they haven't been written yet is because it is difficult
to say when they have been changed. For instance, the ContextResource
would have to determine if the URL is a file url, in which case the logic
is differed to the FileResource or if it is unknown (like IBM's "classloader:"
protocol). If it looks like a classloader resource (i.e. unpacked war file),
then the resource is deferred to the ClassLoaderResource. The ClassLoaderResource
has to assume the resource never changes unless it has a handle on the
enclosing Jar file (not always easy to get). If it can grab that, it can check
to see if the jar file has changed--but that does not guarantee that the
new jar has been loaded....
You see the conundrum?
This is further exacerbated by the fact that the URL does not have any way
of easily determining last modified date. For instance, you might be able
to get it from a "file" url, an "http" url, and an "ftp" url--but you are
at the mercy of the URLConnection subclass that is specific to each of those
protocols.
> Now it's implemented like this:
>
> <code>
> this.monitor = (Monitor)this.componentManager.lookup(Monitor.ROLE);
> URL configURL = new URL(source.getSystemId());
> getLogger().debug("Configuration path=" + configURL.getFile());
> FileResource file = new FileResource(configURL.getFile());
> file.addPropertyChangeListener(this);
> monitor.addResource(file);
> </code>
Currently, that is correct--assuming that the classes you are passing are
indeed PropterChangeListeners...
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
