Re: How-to disable caching for Cocoon2.2 completely

[Joerg Heinicke]

You can switch off caching per pipeline. There is a non-caching 
pipeline. Please don't ask me for details though - too long ago :-)


Joerg

On 17.02.2011 14:42, Robby Pelssers wrote:

I would like to check out the performance without any caching and check if I 
can live with it... if so it will at least solve my corrupted cache issue.

[c3] Log*Transformer

[Reinhard Pötz]

I had to comment the usage of the Log*Transformers in the sample sitemap 
because they break the integration tests (run it.sh or it.bat from C3's 
root directory). The problem is that the logfile is written to the file 
system which doesn't work in a multi-module build (map:parameter 
name=logfile value=target/logasxml.log / - there is no target 
directory at the base directory).


IMO the best idea would be changing the transformer configurations to 
use System.out but the current implementations close the output stream 
in their finish methods. That's of course useful for FileOutputStreams 
but mustn't happen for System.out.


IMO the best solution would be wrapping the usage of System.out with 
Commons IO's CloseShieldOutputStream 
(http://s.apache.org/commons-io-close-shield-outputstream). However, 
this would introduce a dependency of cocoon-sax on commons-io which 
should be avoided for a minor use case like this.


I see two possible solutions:

a) move the Log*Transformers to cocoon-optional and wrap the usage
   of System.out with the CloseShieldOutputStream

b) implement the CloseShield functionality ourselves and leave them
   where they are.

I would prefer option a) because it's the simpler solution and leads to 
less code.


WDYT?

--
Reinhard Pötz Founder  Managing Director, Indoqa and Deepsearch
http://www.indoqa.com/people/reinhard-poetz.html

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  reinh...@apache.org


  Furthermore, I think Oracle has to honor the JSPA agreement.
http://s.apache.org/JCPIsDead   http://s.apache.org/tck-trap

Re: [c3] Log*Transformer

[Francesco Chicchiriccò]

On 18/feb/2011, at 20.28, Reinhard Pötz wrote:

 I had to comment the usage of the Log*Transformers in the sample sitemap 
 because they break the integration tests (run it.sh or it.bat from C3's root 
 directory). The problem is that the logfile is written to the file system 
 which doesn't work in a multi-module build (map:parameter name=logfile 
 value=target/logasxml.log / - there is no target directory at the base 
 directory).
 
 IMO the best idea would be changing the transformer configurations to use 
 System.out but the current implementations close the output stream in their 
 finish methods. That's of course useful for FileOutputStreams but mustn't 
 happen for System.out.
 
 IMO the best solution would be wrapping the usage of System.out with Commons 
 IO's CloseShieldOutputStream 
 (http://s.apache.org/commons-io-close-shield-outputstream). However, this 
 would introduce a dependency of cocoon-sax on commons-io which should be 
 avoided for a minor use case like this.
 
 I see two possible solutions:
 
 a) move the Log*Transformers to cocoon-optional and wrap the usage
   of System.out with the CloseShieldOutputStream
 
 b) implement the CloseShield functionality ourselves and leave them
   where they are.
 
 I would prefer option a) because it's the simpler solution and leads to less 
 code.
 
 WDYT?

What if we choose a third option, like changing

this.outputStream.close();

to

if (System.out.equals(this.outputStream)) {
this.outputStream.flush();
} else {
this.outputStream.close();
}

in the finish() body, for both transformers?

I made these simple modifications (in the attached patch) and, at least on my 
machine, the integration tests are running successfully.

Let me know if this solution is acceptable, thanks.

Regards.



fixlogtransformers.patch
Description: Binary data