cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <>
Subject RE: [RT] Unification of Source/Resource Management (was Re: Adding Resource Monitor to Generators)
Date Tue, 11 Dec 2001 16:11:22 GMT
>From: Berin Loritsch []
>Gerhard Froehlich wrote:
>>>From: Berin Loritsch []
>> </snip>
>>>The ResourceManager should be made Contextualizable so that it can
>>>get the needed reference to the HttpContext object.  It should be
>>>made Configurable so that it can understand how to map protocols to
>>>Resource classes.  It should work with the Cache system and the
>>>Monitor system.
>>>If the Resource type is Cacheable, then the ResourceManager will
>>>take care of the Cache plumbing.  IOW, it will returned the cached
>>>Resource (if available), or create the new reference and add it to
>>>the cache.  Also, if the Resource is used in the caching system,
>>>it is added to the Monitor, and the Cache system is passed as the
>>>PropertyChangedListener--either that, or a different object that
>>>manages the interaction between the two is used.
>> Why so modestly. I thought the Monitor can be used by every Resource,
>> independent if it's Cachable or not. Like the Configuration file(s), etc.
>> How about a interface which marks that Resource Monitorable
>> (bad name, but you know what I mean), then ResourceManager could decide
>> if he puts the Resource to the Monitor or not...
>Think in terms of WHAT needs to be done and WHO needs to do it.  Let's
>say for instance, that the configuration file changed (cocoon.xconf).
>It is the CocoonServlet's responsibility to create a new Cocoon instance
>with the new configuration file, dispose of the old one, and instantiate
>the new one.  Cocoon is not Reconfigurable, so it should never reconfigure
>itself.  This is known as the antipattern Subversion of Control.
>Also, a resource only needs to be monitored as long as it is in use.
>ProgramGenerator needs to know if any of it's source files have been
>altered so that it can recompile the resource and reload it in the
>classloader.  The Cache system only needs to track something as long
>as it is in the cache.
>At all other times, the file can be changed a million times, but if
>it has never been needed why do we need to consume resources observing
>it?  That would end up with too many change events being fired with
>noone listening.

Ok this is my 6th try to write an intelligent contribution to this
issue ;-).

My main problem is I don't really understand how do you want do integrate
this ResourceManagemement this central in the existing Pipline architecture
and how it would be accessable for non Pipline relevant Resources.
I think you can't integrate a PropertyChangeListener this easy into the
Piplines. I think this PropertyChangeListener listener should be nearer
at the Resource. Because when you append it on the Generators for i.e.
we ran into the same problem as I with the ProgramGeneratorImpl.

Errr...Maybe I think to complicated here.


"Three o'clock is always too late or too early for 
anything you want to do.
(Jean-Paul Sartre)"

To unsubscribe, e-mail:
For additional commands, email:

View raw message