Re: [c3] Log*Transformer

2011-03-02 Thread Francesco Chicchiriccò

On 22/02/2011 15:15, Reinhard Pötz wrote:

On 02/21/2011 11:32 AM, Francesco Chicchiriccò wrote:

On 21/feb/2011, at 10.56, Simone Tripodi wrote:


Hi all, I'd tend agree with Reinhard if the CloseShield
functionality is not simple (and I mean very simple, almost silly)
to replicate into our module. I'm sure the CloseShield in the IO
takes care of more general PrintStream use cases rather then just
the sysout, so I'm worried that the proposed patch is not
enough...


For the sake of clarity: I've proposed that naive patch mainly
because I think that Log*Transformers are there to be used only for
dev purpose, where System.out or FileOutpuStream are the only viable
candidates.

Anyway, I've taken a quick look to
http://s.apache.org/commons-io-close-shield-outputstream and its
parent class http://bit.ly/h7AolY: it seems to me that it would be
quite easy to embed these two classes in order to have a CloseShield
functionality in cocoon3-sax.

If you think that it could be useful to have such functionality there
(also for usage by other classes than just Log*Transformers), please
let me know.


I think the patch with the simple approach is good enough in this case 
because the class encapsulates the usage of the output stream 
completely. (It would be different if an output stream was passed to 
the transformer ...)


Since you get commit access to the repository soon, you can apply the 
patch yourself ;-) Congratulations BTW!

Reinhard,
I've just committed the above mentioned patch, with the secondary 
purpose of testing my SVN rights ;-)


About this, do you know how can I ask to align my current JIRA account 
(ilgrosso) to my recent committer rights? Thanks.


Regards.

--
Apache Cocoon Committer

http://people.apache.org/~ilgrosso/



Re: [c3] Log*Transformer

2011-03-02 Thread Reinhard Pötz

On 03/02/2011 10:38 AM, Francesco Chicchiriccò wrote:

About this, do you know how can I ask to align my current JIRA account
(ilgrosso) to my recent committer rights? Thanks.


done

--
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

2011-02-28 Thread Simone Tripodi
Hi again,
Francesco, did you receive your account activation?

If not...: Reinhard, do you know who I have to ping?

Many thanks in advance!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



2011/2/25 Francesco Chicchiriccò francesco.chicchiri...@tirasa.net:
 On 25/02/2011 09:57, Simone Tripodi wrote:

 on a side note: Francesco, did you receive the account activation?
 It's been a while now and looks like it's taking time...
 please let me know!

 Hi Simone,
 unfortunately nothing has arrived so far :-(

 On Tue, Feb 22, 2011 at 3:15 PM, Reinhard Pötzreinh...@apache.org
  wrote:

 On 02/21/2011 11:32 AM, Francesco Chicchiriccò wrote:

 On 21/feb/2011, at 10.56, Simone Tripodi wrote:

 Hi all, I'd tend agree with Reinhard if the CloseShield
 functionality is not simple (and I mean very simple, almost silly)
 to replicate into our module. I'm sure the CloseShield in the IO
 takes care of more general PrintStream use cases rather then just
 the sysout, so I'm worried that the proposed patch is not
 enough...

 For the sake of clarity: I've proposed that naive patch mainly
 because I think that Log*Transformers are there to be used only for
 dev purpose, where System.out or FileOutpuStream are the only viable
 candidates.

 Anyway, I've taken a quick look to
 http://s.apache.org/commons-io-close-shield-outputstream and its
 parent class http://bit.ly/h7AolY: it seems to me that it would be
 quite easy to embed these two classes in order to have a CloseShield
 functionality in cocoon3-sax.

 If you think that it could be useful to have such functionality there
 (also for usage by other classes than just Log*Transformers), please
 let me know.

 I think the patch with the simple approach is good enough in this case
 because the class encapsulates the usage of the output stream completely.
 (It would be different if an output stream was passed to the transformer
 ...)

 Since you get commit access to the repository soon, you can apply the
 patch
 yourself ;-) Congratulations BTW!

 --
 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

 --
 #

 Dott. Francesco Chicchiriccò
 Amministratore unico
 Tel +393290573276

 Tirasa S.r.l.
 Via  Pescara
 Tel / FAX +3908500
 http://www.tirasa.net

 To Iterate is Human, to Recurse, Divine
 (James O. Coplien, Bell Labs)

 #




Re: [c3] Log*Transformer

2011-02-28 Thread Francesco Chicchiriccò

On 28/02/2011 09:28, Simone Tripodi wrote:

Hi again,
Francesco, did you receive your account activation?


No Simone, still nothing here...


If not...: Reinhard, do you know who I have to ping?

Many thanks in advance!


2011/2/25 Francesco Chicchiriccòfrancesco.chicchiri...@tirasa.net:

On 25/02/2011 09:57, Simone Tripodi wrote:

on a side note: Francesco, did you receive the account activation?
It's been a while now and looks like it's taking time...
please let me know!

Hi Simone,
unfortunately nothing has arrived so far :-(

--
#

Dott. Francesco Chicchiriccò
Amministratore unico
Tel +393290573276

Tirasa S.r.l.
Via  Pescara
Tel / FAX +3908500
http://www.tirasa.net

To Iterate is Human, to Recurse, Divine
(James O. Coplien, Bell Labs)

#



Re: [c3] Log*Transformer

2011-02-28 Thread Reinhard Pötz

On 02/28/2011 09:28 AM, Simone Tripodi wrote:

Hi again,
Francesco, did you receive your account activation?

If not...: Reinhard, do you know who I have to ping?


It's not unusual if it takes a week or two to get an account created ...

--
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

2011-02-28 Thread Simone Tripodi
OK thanks, let's wait and be patient :)
have a nice evening, all the best,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Mon, Feb 28, 2011 at 9:34 PM, Reinhard Pötz reinh...@apache.org wrote:
 On 02/28/2011 09:28 AM, Simone Tripodi wrote:

 Hi again,
 Francesco, did you receive your account activation?

 If not...: Reinhard, do you know who I have to ping?

 It's not unusual if it takes a week or two to get an account created ...

 --
 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

2011-02-25 Thread Simone Tripodi
on a side note: Francesco, did you receive the account activation?
It's been a while now and looks like it's taking time...
please let me know!
Simo


http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Feb 22, 2011 at 3:15 PM, Reinhard Pötz reinh...@apache.org wrote:
 On 02/21/2011 11:32 AM, Francesco Chicchiriccò wrote:

 On 21/feb/2011, at 10.56, Simone Tripodi wrote:

 Hi all, I'd tend agree with Reinhard if the CloseShield
 functionality is not simple (and I mean very simple, almost silly)
 to replicate into our module. I'm sure the CloseShield in the IO
 takes care of more general PrintStream use cases rather then just
 the sysout, so I'm worried that the proposed patch is not
 enough...

 For the sake of clarity: I've proposed that naive patch mainly
 because I think that Log*Transformers are there to be used only for
 dev purpose, where System.out or FileOutpuStream are the only viable
 candidates.

 Anyway, I've taken a quick look to
 http://s.apache.org/commons-io-close-shield-outputstream and its
 parent class http://bit.ly/h7AolY: it seems to me that it would be
 quite easy to embed these two classes in order to have a CloseShield
 functionality in cocoon3-sax.

 If you think that it could be useful to have such functionality there
 (also for usage by other classes than just Log*Transformers), please
 let me know.

 I think the patch with the simple approach is good enough in this case
 because the class encapsulates the usage of the output stream completely.
 (It would be different if an output stream was passed to the transformer
 ...)

 Since you get commit access to the repository soon, you can apply the patch
 yourself ;-) Congratulations BTW!

 --
 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

2011-02-25 Thread Francesco Chicchiriccò

On 25/02/2011 09:57, Simone Tripodi wrote:

on a side note: Francesco, did you receive the account activation?
It's been a while now and looks like it's taking time...
please let me know!


Hi Simone,
unfortunately nothing has arrived so far :-(


On Tue, Feb 22, 2011 at 3:15 PM, Reinhard Pötzreinh...@apache.org  wrote:

On 02/21/2011 11:32 AM, Francesco Chicchiriccò wrote:

On 21/feb/2011, at 10.56, Simone Tripodi wrote:


Hi all, I'd tend agree with Reinhard if the CloseShield
functionality is not simple (and I mean very simple, almost silly)
to replicate into our module. I'm sure the CloseShield in the IO
takes care of more general PrintStream use cases rather then just
the sysout, so I'm worried that the proposed patch is not
enough...

For the sake of clarity: I've proposed that naive patch mainly
because I think that Log*Transformers are there to be used only for
dev purpose, where System.out or FileOutpuStream are the only viable
candidates.

Anyway, I've taken a quick look to
http://s.apache.org/commons-io-close-shield-outputstream and its
parent class http://bit.ly/h7AolY: it seems to me that it would be
quite easy to embed these two classes in order to have a CloseShield
functionality in cocoon3-sax.

If you think that it could be useful to have such functionality there
(also for usage by other classes than just Log*Transformers), please
let me know.

I think the patch with the simple approach is good enough in this case
because the class encapsulates the usage of the output stream completely.
(It would be different if an output stream was passed to the transformer
...)

Since you get commit access to the repository soon, you can apply the patch
yourself ;-) Congratulations BTW!

--
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


--
#

Dott. Francesco Chicchiriccò
Amministratore unico
Tel +393290573276

Tirasa S.r.l.
Via  Pescara
Tel / FAX +3908500
http://www.tirasa.net

To Iterate is Human, to Recurse, Divine
(James O. Coplien, Bell Labs)

#



Re: [c3] Log*Transformer

2011-02-22 Thread Reinhard Pötz

On 02/21/2011 11:32 AM, Francesco Chicchiriccò wrote:

On 21/feb/2011, at 10.56, Simone Tripodi wrote:


Hi all, I'd tend agree with Reinhard if the CloseShield
functionality is not simple (and I mean very simple, almost silly)
to replicate into our module. I'm sure the CloseShield in the IO
takes care of more general PrintStream use cases rather then just
the sysout, so I'm worried that the proposed patch is not
enough...


For the sake of clarity: I've proposed that naive patch mainly
because I think that Log*Transformers are there to be used only for
dev purpose, where System.out or FileOutpuStream are the only viable
candidates.

Anyway, I've taken a quick look to
http://s.apache.org/commons-io-close-shield-outputstream and its
parent class http://bit.ly/h7AolY: it seems to me that it would be
quite easy to embed these two classes in order to have a CloseShield
functionality in cocoon3-sax.

If you think that it could be useful to have such functionality there
(also for usage by other classes than just Log*Transformers), please
let me know.


I think the patch with the simple approach is good enough in this case 
because the class encapsulates the usage of the output stream 
completely. (It would be different if an output stream was passed to the 
transformer ...)


Since you get commit access to the repository soon, you can apply the 
patch yourself ;-) Congratulations BTW!


--
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

2011-02-21 Thread Simone Tripodi
Hi all,
I'd tend agree with Reinhard if the CloseShield functionality is not
simple (and I mean very simple, almost silly) to replicate into our
module.
I'm sure the CloseShield in the IO takes care of more general
PrintStream use cases rather then just the sysout, so I'm worried that
the proposed patch is not enough...
Just my 0.02 cents,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



2011/2/18 Francesco Chicchiriccò francesco.chicchiri...@tirasa.net:
 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.




Re: [c3] Log*Transformer

2011-02-21 Thread Francesco Chicchiriccò
On 21/feb/2011, at 10.56, Simone Tripodi wrote:

 Hi all,
 I'd tend agree with Reinhard if the CloseShield functionality is not
 simple (and I mean very simple, almost silly) to replicate into our
 module.
 I'm sure the CloseShield in the IO takes care of more general
 PrintStream use cases rather then just the sysout, so I'm worried that
 the proposed patch is not enough...

For the sake of clarity: I've proposed that naive patch mainly because I think 
that Log*Transformers are there to be used only for dev purpose, where 
System.out or FileOutpuStream are the only viable candidates.

Anyway, I've taken a quick look to 
http://s.apache.org/commons-io-close-shield-outputstream and its parent class 
http://bit.ly/h7AolY: it seems to me that it would be quite easy to embed these 
two classes in order to have a CloseShield functionality in cocoon3-sax.

If you think that it could be useful to have such functionality there (also for 
usage by other classes than just Log*Transformers), please let me know.

Cheers.

 2011/2/18 Francesco Chicchiriccò francesco.chicchiri...@tirasa.net:
 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.


Re: [c3] Log*Transformer

2011-02-18 Thread 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