Hi Johnathan,.
jonathan wood <jonathanshaww...@gmail.com> wrote on 05/18/2010 08:29:49
PM:
> Looks like a double close on an output stream...
IMHO that shouldn't be a problem...
> I believe the solution is to apply the following to org/apache/
> batik/ext/awt/image/codec/png/PNGImageEncoder.java, although I'd
> rely on Thomas DeWeese or other committer to verify.
It seems to me the simplest (and potentially the safest)
would be to modify the IDATOutputStream so that flush does nothing
if no bytes have been written:
Index:
sources/org/apache/batik/ext/awt/image/codec/png/PNGImageEncoder.java
===================================================================
--- sources/org/apache/batik/ext/awt/image/codec/png/PNGImageEncoder.java
(revision 897441)
+++ sources/org/apache/batik/ext/awt/image/codec/png/PNGImageEncoder.java
(working copy)
@@ -211,6 +211,8 @@
}
public void flush() throws IOException {
+ if (bytesWritten == 0) return;
+
// Length
writeInt(bytesWritten);
// 'IDAT' signature
> - removed ios.flush() and ios.close() since DeflaterOutputStream
> claims to complete the stream write and close the close the underlying
stream
It seems to me we have gotten in trouble before when we didn't
close
streams. It's possible that doesn't apply here but still I'd feel better
leaving the close calls. I don't feel quite a strongly about the flush
as it is clear buffered data should be flushed before closing.
Really in my mind the main issue is that you should be able to
call
flush whenever you want and not cause real havok which isn't the case
without the proposed patch.
