>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
>
>Gerhard Froehlich wrote:
>
>>>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>>>
>>
>> </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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
