You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Conor MacNeill <co...@apache.org> on 2011/04/18 08:10:13 UTC
Log Flushing
Nicolas,
The change you introduced to address this bug
https://issues.apache.org/bugzilla/show_bug.cgi?id=50960
really breaks my output when running java processes because the
autoflush is flushing at 128 byte boundaries. The log output stream
always writes a line when flush is called.
Here is an example:
[java] 15:53:53 WARN - Package Scanner found duplicates for
package 'org.w3c.dom' with different ver
[java] sions. Files: xom-1.1.jar and xmlbeans-2.3.0.jar
[java] '/Users/conor/work/fedefault/output/dist/lib/xom-1.1.jar'
[java] '/Users/conor/wor
[java] k/fedefault/output/dist/lib/xmlbeans-2.3.0.jar'
Conor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Log Flushing
Posted by Kevin Jackson <fo...@gmail.com>.
> je suis tres occupe en ce moment a me chercher un nouveau job.
Congratulations.
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Log Flushing
Posted by Antoine Levy Lambert <an...@gmx.de>.
Merci Nicolas,
je suis tres occupe en ce moment a me chercher un nouveau job.
Antoine
On 4/27/11 6:19 PM, Nicolas Lalevée wrote:
> Le 21 avr. 2011 à 23:26, Nicolas Lalevée a écrit :
>
>> Le 21 avr. 2011 à 18:48, Antoine Levy-Lambert a écrit :
>>
>>> I have dived in and committed the code attached to 50507, and also made
>>> flush a no op in LineOrientedOutputStream. See my commits [1] and [2].
>>> Something does not feel 100% right though. In the second commit I have
>>> tweaked unit tests to deal with some consequences of having made flush a
>>> no op.
>>>
>>> see this [3]
>>>
>>> Then the streams really get flushed when they are closed when no carriage return is in the data.
>>>
>>> So if you send "foo", ant was able to redirect "foo" without ending carriage return.
>>>
>>> In the new version the output of copying "foo" is "foo\n".
>>>
>>> Is there a way to avoid that change of behavior ?
>> I guess this is showing another bug in the streams setup. Since the only change you did was about the case where streams get funneled, I am surprised that the streams are funneled when the output is redirected to a property. It would mean that we could catch the bytes from the error stream in the output property. So maybe the condition on the line 720 of Redirector is incorrect. I'm sure though what should be there instead.
> I've looked deeper into this and I have found a solution. See r1097261 [1]. I somehow followed the documentation about the attribute "logError" on the java task [2] which says: "If you redirect error with the "error" or "errorProperty" attributes, this will have no effect."; I understand this as if there is a redirect of the error streams, they should not be mixed up. Which makes sense to me.
>
> Nicolas
>
> [1] http://svn.apache.org/viewvc?view=revision&revision=1097261
> [2] http://ant.apache.org/manual/Tasks/java.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Log Flushing
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 21 avr. 2011 à 23:26, Nicolas Lalevée a écrit :
>
> Le 21 avr. 2011 à 18:48, Antoine Levy-Lambert a écrit :
>
>> I have dived in and committed the code attached to 50507, and also made
>> flush a no op in LineOrientedOutputStream. See my commits [1] and [2].
>> Something does not feel 100% right though. In the second commit I have
>> tweaked unit tests to deal with some consequences of having made flush a
>> no op.
>>
>> see this [3]
>>
>> Then the streams really get flushed when they are closed when no carriage return is in the data.
>>
>> So if you send "foo", ant was able to redirect "foo" without ending carriage return.
>>
>> In the new version the output of copying "foo" is "foo\n".
>>
>> Is there a way to avoid that change of behavior ?
>
> I guess this is showing another bug in the streams setup. Since the only change you did was about the case where streams get funneled, I am surprised that the streams are funneled when the output is redirected to a property. It would mean that we could catch the bytes from the error stream in the output property. So maybe the condition on the line 720 of Redirector is incorrect. I'm sure though what should be there instead.
I've looked deeper into this and I have found a solution. See r1097261 [1]. I somehow followed the documentation about the attribute "logError" on the java task [2] which says: "If you redirect error with the "error" or "errorProperty" attributes, this will have no effect."; I understand this as if there is a redirect of the error streams, they should not be mixed up. Which makes sense to me.
Nicolas
[1] http://svn.apache.org/viewvc?view=revision&revision=1097261
[2] http://ant.apache.org/manual/Tasks/java.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Log Flushing
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 21 avr. 2011 à 18:48, Antoine Levy-Lambert a écrit :
> I have dived in and committed the code attached to 50507, and also made
> flush a no op in LineOrientedOutputStream. See my commits [1] and [2].
> Something does not feel 100% right though. In the second commit I have
> tweaked unit tests to deal with some consequences of having made flush a
> no op.
>
> see this [3]
>
> Then the streams really get flushed when they are closed when no carriage return is in the data.
>
> So if you send "foo", ant was able to redirect "foo" without ending carriage return.
>
> In the new version the output of copying "foo" is "foo\n".
>
> Is there a way to avoid that change of behavior ?
I guess this is showing another bug in the streams setup. Since the only change you did was about the case where streams get funneled, I am surprised that the streams are funneled when the output is redirected to a property. It would mean that we could catch the bytes from the error stream in the output property. So maybe the condition on the line 720 of Redirector is incorrect. I'm sure though what should be there instead.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Log Flushing
Posted by Antoine Levy-Lambert <an...@gmx.de>.
I have dived in and committed the code attached to 50507, and also made
flush a no op in LineOrientedOutputStream. See my commits [1] and [2].
Something does not feel 100% right though. In the second commit I have
tweaked unit tests to deal with some consequences of having made flush a
no op.
see this [3]
Then the streams really get flushed when they are closed when no carriage return is in the data.
So if you send "foo", ant was able to redirect "foo" without ending carriage return.
In the new version the output of copying "foo" is "foo\n".
Is there a way to avoid that change of behavior ?
[1] http://svn.apache.org/viewvc?view=revision&revision=1095736
[2] http://svn.apache.org/viewvc?view=revision&revision=1095768
[3] http://svn.apache.org/viewvc/ant/core/trunk/src/etc/testcases/taskdefs/java.xml?r1=1086741&r2=1095768&pathrev=1095768&diff_format=h
Regards,
Antoine
On 4/19/11 5:51 PM, Antoine Levy-Lambert wrote:
> I just created a test for the bug 50507. I did this one as JUnit, not
> AntUnit although it is similar in its form to AntUnit. The capturing
> of the output of the "ant" task did not seem to work when running all
> this in the context of antunit.
> Stefan might have an idea why ?
>
>
> Antoine
>
> On 4/19/2011 11:56 AM, Nicolas Lalevée wrote:
>> Le 19 avr. 2011 à 16:42, Antoine Levy-Lambert a écrit :
>>
>>> On 4/19/2011 8:29 AM, Nicolas Lalevée wrote:
>>>> Thank you very much for the pointers. The patch for the bug report
>>>> #50507 seems to tackle the streaming issue.
>>>>
>>>> I guess that in Ant we always want to see the log by line, rather
>>>> than with usual unix tools where the output is streamed. With unix
>>>> tools, streaming is useful when pipelining commands. I guess we
>>>> never do that with Ant.
>>>>
>>>> In the suggested patch, line ending "awareness" is only enabled
>>>> when we merge both the standard output stream and the error one.
>>> I think the line ending awareness is enabled by the patch in the
>>> case when there is no redirection of either standard err or standard
>>> out to files or properties. I do not think it is the same as merging
>>> standard out and standard err, except that if a line of standard err
>>> is produced by the executable between two lines of standard out it
>>> will be visible that way.
>>>
>>> If one of the two stream, out and err, is not redirected to a file
>>> or copied to a property, lines should still be preserved, so other
>>> use cases should be changed functionally if currently they break lines.
>> Well, if the two streams are not merged, then there should not be any
>> issue then, as each stream will push things into its own "thing".
>> "thing" being a file, or a socket, or even a wrapped standard stream.
>> In that last case of the "wrapped standard stream", it is then the
>> responsibility of the wrapper to properly output it I think.
>>
>> But as you pointed to me in the chat, there is indeed some issue with
>> the LineOrientedOutputStream which is quite sensible with too many
>> flush. It will create a new line on each flush.
>> I then suggest to make the LineOrientedOutputStream#flush function do
>> nothing, which will fix Conor's bug.
>> And the patch in #50507 will actually just fix the bug #50507.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Log Flushing
Posted by Antoine Levy-Lambert <an...@gmx.de>.
I just created a test for the bug 50507. I did this one as JUnit, not
AntUnit although it is similar in its form to AntUnit. The capturing of
the output of the "ant" task did not seem to work when running all this
in the context of antunit.
Stefan might have an idea why ?
Antoine
On 4/19/2011 11:56 AM, Nicolas Lalevée wrote:
> Le 19 avr. 2011 à 16:42, Antoine Levy-Lambert a écrit :
>
>> On 4/19/2011 8:29 AM, Nicolas Lalevée wrote:
>>> Thank you very much for the pointers. The patch for the bug report #50507 seems to tackle the streaming issue.
>>>
>>> I guess that in Ant we always want to see the log by line, rather than with usual unix tools where the output is streamed. With unix tools, streaming is useful when pipelining commands. I guess we never do that with Ant.
>>>
>>> In the suggested patch, line ending "awareness" is only enabled when we merge both the standard output stream and the error one.
>> I think the line ending awareness is enabled by the patch in the case when there is no redirection of either standard err or standard out to files or properties. I do not think it is the same as merging standard out and standard err, except that if a line of standard err is produced by the executable between two lines of standard out it will be visible that way.
>>
>> If one of the two stream, out and err, is not redirected to a file or copied to a property, lines should still be preserved, so other use cases should be changed functionally if currently they break lines.
> Well, if the two streams are not merged, then there should not be any issue then, as each stream will push things into its own "thing". "thing" being a file, or a socket, or even a wrapped standard stream. In that last case of the "wrapped standard stream", it is then the responsibility of the wrapper to properly output it I think.
>
> But as you pointed to me in the chat, there is indeed some issue with the LineOrientedOutputStream which is quite sensible with too many flush. It will create a new line on each flush.
> I then suggest to make the LineOrientedOutputStream#flush function do nothing, which will fix Conor's bug.
> And the patch in #50507 will actually just fix the bug #50507.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Log Flushing
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 19 avr. 2011 à 16:42, Antoine Levy-Lambert a écrit :
> On 4/19/2011 8:29 AM, Nicolas Lalevée wrote:
>> Thank you very much for the pointers. The patch for the bug report #50507 seems to tackle the streaming issue.
>>
>> I guess that in Ant we always want to see the log by line, rather than with usual unix tools where the output is streamed. With unix tools, streaming is useful when pipelining commands. I guess we never do that with Ant.
>>
>> In the suggested patch, line ending "awareness" is only enabled when we merge both the standard output stream and the error one.
> I think the line ending awareness is enabled by the patch in the case when there is no redirection of either standard err or standard out to files or properties. I do not think it is the same as merging standard out and standard err, except that if a line of standard err is produced by the executable between two lines of standard out it will be visible that way.
>
> If one of the two stream, out and err, is not redirected to a file or copied to a property, lines should still be preserved, so other use cases should be changed functionally if currently they break lines.
Well, if the two streams are not merged, then there should not be any issue then, as each stream will push things into its own "thing". "thing" being a file, or a socket, or even a wrapped standard stream. In that last case of the "wrapped standard stream", it is then the responsibility of the wrapper to properly output it I think.
But as you pointed to me in the chat, there is indeed some issue with the LineOrientedOutputStream which is quite sensible with too many flush. It will create a new line on each flush.
I then suggest to make the LineOrientedOutputStream#flush function do nothing, which will fix Conor's bug.
And the patch in #50507 will actually just fix the bug #50507.
>> So if somebody really want to do output stream pipelining, he most probably doesn't want mixing these streams. For such used case, the best approach would then be to extends the ExecTask and override createHandler() to implement its proper pipelining.
I was talking about doing stuff like this:
$ svn status | grep -e "^\?" | cut -d " " -f 8
But looking closer we do have such things in Ant with the redirector stuff. So forget what I wrote.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Log Flushing
Posted by Antoine Levy-Lambert <an...@gmx.de>.
On 4/19/2011 8:29 AM, Nicolas Lalevée wrote:
> Thank you very much for the pointers. The patch for the bug report #50507 seems to tackle the streaming issue.
>
> I guess that in Ant we always want to see the log by line, rather than with usual unix tools where the output is streamed. With unix tools, streaming is useful when pipelining commands. I guess we never do that with Ant.
>
> In the suggested patch, line ending "awareness" is only enabled when we merge both the standard output stream and the error one.
I think the line ending awareness is enabled by the patch in the case
when there is no redirection of either standard err or standard out to
files or properties. I do not think it is the same as merging standard
out and standard err, except that if a line of standard err is produced
by the executable between two lines of standard out it will be visible
that way.
If one of the two stream, out and err, is not redirected to a file or
copied to a property, lines should still be preserved, so other use
cases should be changed functionally if currently they break lines.
> So if somebody really want to do output stream pipelining, he most probably doesn't want mixing these streams. For such used case, the best approach would then be to extends the ExecTask and override createHandler() to implement its proper pipelining.
>
I am not sure I understand.
> Sounds reasonable ?
>
> Nicolas
Regards,
Antoine
> Le 18 avr. 2011 à 23:13, Antoine Levy-Lambert a écrit :
>
>> In fact we have a number of open bugs concerning the handling of streams in exec and java :
>>
>> [1] Pipe Broken
>> [2] Exec task may mix the stderr and stdout output while logging it
>> [3] exec task sometimes inserts extraneous newlines
>> [4] read on System.in hangs for forked java task
>>
>> Antoine
>>
>> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=48789
>> [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=50507
>> [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=48746
>> [4] https://issues.apache.org/bugzilla/show_bug.cgi?id=50960
>>
>>
>> On 4/18/2011 4:03 PM, Antoine Levy-Lambert wrote:
>>> there is an interesting patch in this bug report :
>>>
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50507
>>>
>>> Regards,
>>>
>>> Antoine
>>>
>>> On 4/18/2011 4:14 AM, Nicolas Lalevée wrote:
>>>> Le 18 avr. 2011 à 08:10, Conor MacNeill a écrit :
>>>>
>>>>> Nicolas,
>>>>>
>>>>> The change you introduced to address this bug
>>>>>
>>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50960
>>>>>
>>>>> really breaks my output when running java processes because the
>>>>> autoflush is flushing at 128 byte boundaries. The log output stream
>>>>> always writes a line when flush is called.
>>>>>
>>>>> Here is an example:
>>>>>
>>>>> [java] 15:53:53 WARN - Package Scanner found duplicates for
>>>>> package 'org.w3c.dom' with different ver
>>>>> [java] sions. Files: xom-1.1.jar and xmlbeans-2.3.0.jar
>>>>> [java] '/Users/conor/work/fedefault/output/dist/lib/xom-1.1.jar'
>>>>> [java] '/Users/conor/wor
>>>>> [java] k/fedefault/output/dist/lib/xmlbeans-2.3.0.jar'
>>>> hum...
>>>> I guess that more than a simple "autoflush" we should have something like an "autoflush-on-end-of-line".
>>>> I'll try something.
>>>>
>>>> Nicolas
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Log Flushing
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Thank you very much for the pointers. The patch for the bug report #50507 seems to tackle the streaming issue.
I guess that in Ant we always want to see the log by line, rather than with usual unix tools where the output is streamed. With unix tools, streaming is useful when pipelining commands. I guess we never do that with Ant.
In the suggested patch, line ending "awareness" is only enabled when we merge both the standard output stream and the error one. So if somebody really want to do output stream pipelining, he most probably doesn't want mixing these streams. For such used case, the best approach would then be to extends the ExecTask and override createHandler() to implement its proper pipelining.
Sounds reasonable ?
Nicolas
Le 18 avr. 2011 à 23:13, Antoine Levy-Lambert a écrit :
> In fact we have a number of open bugs concerning the handling of streams in exec and java :
>
> [1] Pipe Broken
> [2] Exec task may mix the stderr and stdout output while logging it
> [3] exec task sometimes inserts extraneous newlines
> [4] read on System.in hangs for forked java task
>
> Antoine
>
> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=48789
> [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=50507
> [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=48746
> [4] https://issues.apache.org/bugzilla/show_bug.cgi?id=50960
>
>
> On 4/18/2011 4:03 PM, Antoine Levy-Lambert wrote:
>> there is an interesting patch in this bug report :
>>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50507
>>
>> Regards,
>>
>> Antoine
>>
>> On 4/18/2011 4:14 AM, Nicolas Lalevée wrote:
>>> Le 18 avr. 2011 à 08:10, Conor MacNeill a écrit :
>>>
>>>> Nicolas,
>>>>
>>>> The change you introduced to address this bug
>>>>
>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50960
>>>>
>>>> really breaks my output when running java processes because the
>>>> autoflush is flushing at 128 byte boundaries. The log output stream
>>>> always writes a line when flush is called.
>>>>
>>>> Here is an example:
>>>>
>>>> [java] 15:53:53 WARN - Package Scanner found duplicates for
>>>> package 'org.w3c.dom' with different ver
>>>> [java] sions. Files: xom-1.1.jar and xmlbeans-2.3.0.jar
>>>> [java] '/Users/conor/work/fedefault/output/dist/lib/xom-1.1.jar'
>>>> [java] '/Users/conor/wor
>>>> [java] k/fedefault/output/dist/lib/xmlbeans-2.3.0.jar'
>>> hum...
>>> I guess that more than a simple "autoflush" we should have something like an "autoflush-on-end-of-line".
>>> I'll try something.
>>>
>>> Nicolas
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Log Flushing
Posted by Antoine Levy-Lambert <an...@gmx.de>.
In fact we have a number of open bugs concerning the handling of streams
in exec and java :
[1] Pipe Broken
[2] Exec task may mix the stderr and stdout output while logging it
[3] exec task sometimes inserts extraneous newlines
[4] read on System.in hangs for forked java task
Antoine
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=48789
[2] https://issues.apache.org/bugzilla/show_bug.cgi?id=50507
[3] https://issues.apache.org/bugzilla/show_bug.cgi?id=48746
[4] https://issues.apache.org/bugzilla/show_bug.cgi?id=50960
On 4/18/2011 4:03 PM, Antoine Levy-Lambert wrote:
> there is an interesting patch in this bug report :
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50507
>
> Regards,
>
> Antoine
>
> On 4/18/2011 4:14 AM, Nicolas Lalevée wrote:
>> Le 18 avr. 2011 à 08:10, Conor MacNeill a écrit :
>>
>>> Nicolas,
>>>
>>> The change you introduced to address this bug
>>>
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50960
>>>
>>> really breaks my output when running java processes because the
>>> autoflush is flushing at 128 byte boundaries. The log output stream
>>> always writes a line when flush is called.
>>>
>>> Here is an example:
>>>
>>> [java] 15:53:53 WARN - Package Scanner found duplicates for
>>> package 'org.w3c.dom' with different ver
>>> [java] sions. Files: xom-1.1.jar and xmlbeans-2.3.0.jar
>>> [java] '/Users/conor/work/fedefault/output/dist/lib/xom-1.1.jar'
>>> [java] '/Users/conor/wor
>>> [java] k/fedefault/output/dist/lib/xmlbeans-2.3.0.jar'
>> hum...
>> I guess that more than a simple "autoflush" we should have something
>> like an "autoflush-on-end-of-line".
>> I'll try something.
>>
>> Nicolas
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Log Flushing
Posted by Conor MacNeill <co...@apache.org>.
One other possibility is to not bother doing anything in the
LogOutputStream when flushed.
Conor
On Tue, Apr 19, 2011 at 06:03, Antoine Levy-Lambert <an...@gmx.de> wrote:
> there is an interesting patch in this bug report :
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50507
>
> Regards,
>
> Antoine
>
> On 4/18/2011 4:14 AM, Nicolas Lalevée wrote:
>>
>> Le 18 avr. 2011 à 08:10, Conor MacNeill a écrit :
>>
>>> Nicolas,
>>>
>>> The change you introduced to address this bug
>>>
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50960
>>>
>>> really breaks my output when running java processes because the
>>> autoflush is flushing at 128 byte boundaries. The log output stream
>>> always writes a line when flush is called.
>>>
>>> Here is an example:
>>>
>>> [java] 15:53:53 WARN - Package Scanner found duplicates for
>>> package 'org.w3c.dom' with different ver
>>> [java] sions. Files: xom-1.1.jar and xmlbeans-2.3.0.jar
>>> [java] '/Users/conor/work/fedefault/output/dist/lib/xom-1.1.jar'
>>> [java] '/Users/conor/wor
>>> [java] k/fedefault/output/dist/lib/xmlbeans-2.3.0.jar'
>>
>> hum...
>> I guess that more than a simple "autoflush" we should have something like
>> an "autoflush-on-end-of-line".
>> I'll try something.
>>
>> Nicolas
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Log Flushing
Posted by Antoine Levy-Lambert <an...@gmx.de>.
there is an interesting patch in this bug report :
https://issues.apache.org/bugzilla/show_bug.cgi?id=50507
Regards,
Antoine
On 4/18/2011 4:14 AM, Nicolas Lalevée wrote:
> Le 18 avr. 2011 à 08:10, Conor MacNeill a écrit :
>
>> Nicolas,
>>
>> The change you introduced to address this bug
>>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50960
>>
>> really breaks my output when running java processes because the
>> autoflush is flushing at 128 byte boundaries. The log output stream
>> always writes a line when flush is called.
>>
>> Here is an example:
>>
>> [java] 15:53:53 WARN - Package Scanner found duplicates for
>> package 'org.w3c.dom' with different ver
>> [java] sions. Files: xom-1.1.jar and xmlbeans-2.3.0.jar
>> [java] '/Users/conor/work/fedefault/output/dist/lib/xom-1.1.jar'
>> [java] '/Users/conor/wor
>> [java] k/fedefault/output/dist/lib/xmlbeans-2.3.0.jar'
> hum...
> I guess that more than a simple "autoflush" we should have something like an "autoflush-on-end-of-line".
> I'll try something.
>
> Nicolas
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Log Flushing
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 18 avr. 2011 à 08:10, Conor MacNeill a écrit :
> Nicolas,
>
> The change you introduced to address this bug
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50960
>
> really breaks my output when running java processes because the
> autoflush is flushing at 128 byte boundaries. The log output stream
> always writes a line when flush is called.
>
> Here is an example:
>
> [java] 15:53:53 WARN - Package Scanner found duplicates for
> package 'org.w3c.dom' with different ver
> [java] sions. Files: xom-1.1.jar and xmlbeans-2.3.0.jar
> [java] '/Users/conor/work/fedefault/output/dist/lib/xom-1.1.jar'
> [java] '/Users/conor/wor
> [java] k/fedefault/output/dist/lib/xmlbeans-2.3.0.jar'
hum...
I guess that more than a simple "autoflush" we should have something like an "autoflush-on-end-of-line".
I'll try something.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org