[
https://issues.apache.org/jira/browse/COMPRESS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972830#comment-15972830
]
Stefan Bodewig commented on COMPRESS-385:
-----------------------------------------
[~talli...@apache.org] I've tweaked your patch a little, the only real change
is that I now allow 7z to be detected as well - trying to obtain a stream will
still throw an exception, though. I can imagine that Tika would benefit from
detecting a 7z archive as well.
> wouldn't users have gotten a ClassNotFoundException (NoClassDefError?) before
> if they had called the 2 parameter createCompressorInputStream; now they're
> getting a CompressorException.
yes, right, so not only does the message change, the type of exception does as
well.
I'm not sure what to make from the test errors you see,
https://builds.apache.org/job/Commons-Compress-Windows/ seems to be fine. We
probably should try to identify and fix the problem in a different issue.
Many thanks!
> Add detect() to CompressorStreamFactory
> ---------------------------------------
>
> Key: COMPRESS-385
> URL: https://issues.apache.org/jira/browse/COMPRESS-385
> Project: Commons Compress
> Issue Type: Improvement
> Reporter: Tim Allison
> Priority: Minor
> Fix For: 1.14
>
>
> On TIKA-1631, several users have requested that we try to avoid an OOM when a
> corrupted Z file is "detected" by CompressorStreamFactory.
> In Tika, for detection, we're creating the stream via CompressorStreamFactory
> and then "detecting" based on what stream was created. Given that there can
> be some overhead in creating the stream and that there can be an OOM for a
> corrupt Z file, it would be great to add a {{detect(InputStream is)}} option
> in CompressorStreamFactory.
> PR on way.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
