[C1][ XSLTProcessor][bug] we still have a Monitor bug

[Tagunov Anthony <at...@nnt.ru>]

On Fri, 01 Dec 2000 17:49:50 -0000, Robin Green wrote:

>Fixed, thanks. You also made me notice another related bug, so double 
>thanks! ;-)
>
>"Tagunov Anthony" <at...@nnt.ru> wrote:
>
>>
>>if I apply
>>       d.xsl
>>to
>>      d.xml
>>1) request d.xml from server
>>2) change
>>      d.xml
>>    to use
>>      e.xsl
>>3) request
>>      d.xml
>>from server
>>4) edit
>>      d.xsl
>>   (which is no longer used for processing d.xml)
>>5) request d.xml from server and SEE THAT IT WAS NOT TAKEN FROM CACHE 
>>(judging by the time required for processing)
>>
>>In short monitor in XSLTProcessor never gets cleaned.
>>

Hello, Robin!

There are still two and a half things that worry me with theese monitor puzzles:

1) With XSP processor we VERY OFTEN invoke XSP processor AFTER XSLT processor (I know it was not meant for this, and that we have to "touch"
the source .xml every time we change any of the .xsl that preceed XSP processing). It would be nice to find a way to handle this. (In fact, XSP processor does
an "INTERMEDIATE CACHING" (in the form of .java and .class files on the HDD). and it is this problem with intermediate caching that actually is difficult to handle.

2) With the LATEST VERSION OF XSLT processor, what if we have  .xml --(xslt transform via file1.xsl)-->(xslt transform via file2.xsl) ? We'll have only file2.xsl in
the monitor, and changes to file1.xsl won't get detected by the Cocoon caching mechanisms..

3) (very little) If we have XSLT processor process file.xml with file.xsl and then we remove the <?cocoon-process type="text/xsl"?> instruction from file.xml, 
file.xsl will still remain in the requestMonitor of the XSLT processor... this just not nice and unharmfull though (or will it spoil anything with a WeakHashMap in the Store for
Cocoon2?)

Actually I do not see a good way out.. Maybe it's better presently to revert to the previoius practice and never clean this monitor (as use 2) is VERY COMMON, in
our applications at least.

I did not have any time to take a look at Cocoon2 yet, I hope the scheme with Monitors in every processor IS NOT RETAINED THERE, is it?
Speaking of my personal vision the monitors in processors are not very good, because
            we hit situations like 2) and 3) above with monitors in processors...
To my view it would be preferrable to keep all the information that is currently kept in 
  Monitors of the  Processors 
in the 
  Changebles of the Page object..

This way, 
  -- they would automatically vanish every time a page is being created anew, 
  -- we would be able to keep dependencies per each PASS of a processor over the Page, not per PROCESSOR per Page (see problem 2)).
  -- tracing what Resources each PASS of a processor over Page depends on, we could calculate a lastModified time (as the maximum of the lastModified of
     all the dependencies) and thus solve problem 1)

Best regards,
Tagunov Anthony
NNT Telecom Russia