Re: [c3] Log*Transformer
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
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
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
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
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
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
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
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
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
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
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.
[c3] Log*Transformer
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
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
