Bug report in SourceWritingTransformer (C2.0.2 with scratchpad)

[ROSSEL Olivier <ol...@airbus.com>]

*1* The archive:
This simple Cocooon app is made to show a bug in the
SourceWritingTransformer.
Decompress it into your mount/ directory.


*2* The URL:
try to access the URL:
http://yourServerName:serverPort/path/to/cocoon/mount/SourceWritingTest/

*3* The XML in the browser:
Then you will see a XML that is made of two parts:
first part is the report of a sourceWriting transformer into the file
input.xml.
The second part is simply the content of this file.

*4* The theorical behaviour:
The (only) pipeline is made to increment automatically the content of the
<foobar> element of the file input.xml, each time the pipeline is executed.

*5* The real behaviour:
But if you use reload several times in your browser, you see that the 
increment is done only once in two reloads.

*6* The sitemap:
Having a look at the sitemap, you will see that the file input.xml
is accessed both by the generator and by the sourceWriting transformer.

*6* The possible problem:
The problem seems to be that the SourceWriting transformer cannot
update the file because it is "locked" by the generator.
This lock is released when the generator uses the cache to get the content 
of the file instead of the file itself. In that case, the file is not locked
and the SourceWriting transformer can update the file without problem.

*7* The (BIG) bug:
The bug is that the sourceWriting transformer always reports "success"
even if the file could not be updated at all.

*8*: The wish:
Correcting the sourceWriting transformer reporting code is necessary.
Or you will never be sure if the sourceWriting transformer
really made the job.

The best thing is to be able to read AND write a file in the same pipeline,
and have the correct reporting.

*9* THE END !!!

Re: Bug report in SourceWritingTransformer (C2.0.2 with scratchpad)

[Jeremy Quinn <sh...@mac.com>]

I am sorry it has taken me so long to reply.


On Monday, May 27, 2002, at 03:10 PM, ROSSEL Olivier wrote:

> *6* The possible problem:
> The problem seems to be that the SourceWriting transformer cannot
> update the file because it is "locked" by the generator.
> This lock is released when the generator uses the cache to get 
> the content
> of the file instead of the file itself. In that case, the file 
> is not locked
> and the SourceWriting transformer can update the file without problem.
>

I believe this is causing the problem, I've discussed it with 
Sylvain and others in the past and we have nothing conclusive 
yet.


> *7* The (BIG) bug:
> The bug is that the sourceWriting transformer always reports "success"
> even if the file could not be updated at all.
>

That a real nuisance, but can't be solved until we understand 
the underlying problem.

> *8*: The wish:
> Correcting the sourceWriting transformer reporting code is necessary.
> Or you will never be sure if the sourceWriting transformer
> really made the job.
>
> The best thing is to be able to read AND write a file in the 
> same pipeline,
> and have the correct reporting.

This is what I really hoped to be able to do with SWT 
originally, I was building up to it in the samples in 
<slash-edit/>, but others beat me to find the problem ;)

All my samples so far generate the whole source from the Request 
and do not generate from the source being altered, as you do.

As a workaround, if you have data to insert into a larger 
source, try out Carsten's great new <source:insert/> addition to 
SWT (in the HEAD branch only), it allows you to do the insert 
XML into a Source using an XPath directly, not using XSLT as you 
are at the moment, saving you the need to Generate from the same 
Source as you are modifying.

Meanwhile, it would be great to solve the problems with pipeline 
having simultaneous reads and writes to the same Source failing. 
Can this be "co-ordinated" at the Source level?

TBH, I am still struggling to work out what could be going wrong.

If SWT is writing the whole Source (to a temporary file), the 
FileGenerator must have finished reading that Source by the time 
SWT detects the closing <source:write> tag and, having already 
passed the closing tag of the Generated Source, attempts to 
replace the original Source file with the new one?


regards Jeremy


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