https://bz.apache.org/bugzilla/show_bug.cgi?id=60963
--- Comment #7 from Christopher Schultz <ch...@christopherschultz.net> --- (In reply to Thomas Meyer from comment #6) > Regarding ZipInputStreamWithPosition: > I think you found the ugly part of this patch. I guess your suggestion > wouldn't work, because ZipInputStream will construct itself with a new > PushBackInputstream and the provided input stream as decorated object. > Passing the input stream as you suggest would result in a > PushBackInputStream with an PushBackInputStreamWithPosition as decorated > object, which is wrong for our intention here. > By setting the decorated object after the super constructor has finished we > replace the PushbsckInputStream with our implementation. I'm sorry, I don't follow. What's the problem with the superclass's constructor using the PushbackCountingInputStream instead of handing it an undecorated InputStream, and then replacing it after the constructor has completed? Does the superclass constructor do something with the InputStream that we don't want to happen to the PushbackCountingInputStream? I would think that "bytesread" would be incorrect (initialized to zero) if the superclass constructor performs a read. Don't you want those reads to be counted? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
