Huge refactor and stabilize #13
Conversation
- does not hide Exceptions in RuntimeExceptions - behaves like a java.util.Iterator - formally does not implement java.util.Iterator
We now can feed ZipInputStream from Vertx Buffers. No need to duplicate Vertx Buffer as byte[] in-memory
- ResourceMirrorHandler still is the entry-point for ALL Mirror-Requests - it spins of one instance of MirrorRequestHandler for each single MirrorRequest. This enables us to have instance variables (a 'state' resp. 'config') and avoids methods with large number of parameters - Task to iterate over the ZIP and PUT each entry is extracted to class ZipEntryPutter Additionally: - simplified execution paths - clear http-response-code: "200 OK" only when whole MirrorRequest was successful without any problems
| if (pos >= buffer.length()) { | ||
| return -1; | ||
| } | ||
| return buffer.getByte(pos++) & 0xFF; |
There was a problem hiding this comment.
What do we need this bitmask (0xFF) for? Is it required somehow?
According to vertx Buffer doc getByte returns a byte and IMO cannot return any values where this filter would change something.
Am I missing the point?
There was a problem hiding this comment.
a byte is -128 ... +127 in Java.
But when InputStream#read() returns -1 this indicates 'end of stream' - so we must not return -1 when this is a 'read byte'
| return false; | ||
| } | ||
| String filename = ze.getName(); | ||
| if (!filename.endsWith("/")) { |
There was a problem hiding this comment.
Can we really have filenames in a zip stream that represents not files but folders?
And yeah, I know that for e.g. ZipOutputStream can handle empty directories by adding a forward-slash / after the folder name. But can we really have this here?
There was a problem hiding this comment.
It was so in the old implementation - 'directories' (identified by trailing slash) where explicit skipped.
And obviously yes, 'directories' can be listed in a ZIP - for whatever reason
Solves #12
Various issues addressed:
ZipIterator(as a replacement forZipFileEntryIterator) whichthrows IOExceptionin method signature)BufferWrapperInputStreamto directly feed ZipInputStream from Vertx Buffers. No need to duplicate Vertx Buffer as byte[] in-memoryResourceMirrorHandlerinto three classes:ResourceMirrorHandleris still is the entry-point for all Mirror-RequestsMirrorRequestHandler. This enables us to have instance variables (state, config) and avoids methods with large number of parametersZipEntryPutter