Hi Stefan, I like having predefined behaviors in the enum but it does not seem to allow for extension. I am wondering if we would be better served by using an interface invoked by a callback mechanism where predefined implementations exist for the enum values you now have. I would see in addition, a SystemOut impl that printfs these extra fields we do not handle.
Gary On Tue, Aug 13, 2019 at 3:01 PM Stefan Bodewig <bode...@apache.org> wrote: > Hi > > https://issues.apache.org/jira/browse/COMPRESS-479 highlights a problem > where our zip reading code may reject an archive because it uses extra > fields that we only partially understand. In this case the archive is > not a real one, but it is easy to envision extra fields in the wild that > use more advanced versions than we currently support. > > For most of our users the ZIP extra fields will be noise and they really > are only interested in the actual content of the archives. > > Therefore I have decided to treat any such "not quite as we expect" > extra field the same way as any "we have no idea how this extra field > looks internally" field - i.e. just store it but don't try to parse > it. > > In addition I have provided an API inside of ZipArchiveEntry that allows > users to specify in detail how strict they want the extra field parsing > to be. > > Does this make sense to you? Would you recommend taking a different > approach? And it if makes sense, are the enum names I've chosen in > > https://github.com/apache/commons-compress/blob/2bf678bbc6c6002569559b90ea29a031f035f067/src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveEntry.java#L1117 > understandable? > > Thanks > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
