cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <g-froehl...@gmx.de>
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 [mailto:bloritsch@apache.org]
>
>
>Gerhard Froehlich wrote:
>
>>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>>
>> 
>> </snip>
>> 
>>>COCOON IMPLEMENTATION DETAILS
>>>-----------------------------
>>>
>>>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.

    Gerhard

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



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message