tballison commented on PR #3535:
URL: https://github.com/apache/tika/pull/3535#issuecomment-6666101154

   Bot recs. Again, an example file would be great if it is synthetic or asf 
2.0 friendly, but not required. 
   
   ```
   Must fix
   
     1. Component name mismatch (Cr3Parser.java:79 vs :166). A bare 
@TikaComponent turns Cr3Parser into the name
        cr-3-parser; I confirmed this in the generated META-INF registry. But 
the parser looks up its per-request config
        under "cr3-parser". The result is that the name users put in 
tika-config and the name the parse context checks
        are different, so a per-request ImageMetadataConfig for this parser is 
silently ignored. MP4Parser and Mp3Parser
        hit the same thing and set the name explicitly. Fix: 
@TikaComponent(name = "cr3-parser").
     2. docs/modules/ROOT/partials/supported-formats.adoc was not regenerated. 
It should gain a Cr3Parser /
        image/x-canon-cr3 entry. TikaCLITest fails when that file is stale, so 
CI should go red (checks are still
        pending).
   
     Should fix
   
     3. Embedded previews have no resource name. RawTiffParser names its 
previews with
        EmbeddedDocumentUtil.setGeneratedResourceName (THUMBNAIL prefix for the 
large preview, IMAGE prefix for the
        smaller ones); emit() here sets nothing. That affects file names in 
/unpack output. Easy to align.
     4. testLengthBeyondTheBoxIsIgnored doesn't test the box bound. It writes 
Integer.MAX_VALUE as the length, which the
        64 MB cap also rejects. If you deleted the jpegLength > box.end - jpeg 
check, the test would still pass. A length
        of prvw.length + 10 would be a real test: it runs into mdat, the JPEG 
still starts with FFD8, and without the
        check the parser would emit a truncated or garbage JPEG.
   
     Test gaps (minor)
     - The Canon maker note block (CMT3, read starting in 
CanonMakernoteDirectory) has no synthetic test. Only the
       author's hand check against 14 sample files covers it.
     - Every test calls Cr3Parser directly. Nothing checks that 
AutoDetectParser now sends image/x-canon-cr3 to Cr3Parser
       instead of the MP4 parser, which is the bug the PR fixes. One assertion 
in the standard-package integration tests
       would cover it.
   ```
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to