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
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
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 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 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 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ò: 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
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ò : > 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ö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 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 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ö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 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 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 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 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 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ò :
>> 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 (>> 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
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ò :
> 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 (> 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 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 ( 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
