[SLING-6976] ContentLoader.binaryFile() and ContentLoader.binaryResource() should try to derive mimetype from classpath resource rather than from target resource name

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: Testing Sling Mock 2.2.12
• Fix Version/s: Testing Sling Mock 1.9.10, Testing Sling Mock 2.2.14
• Component/s: Testing
• Assignee: Stefan Seifert
• Reporter: Konrad Windszus
• Created: 21/Jun/17 12:39
• Updated: 17/Oct/17 12:54
• Resolved: 21/Jun/17 20:08

Description

Currently the ContentLoader.binaryFile tries to derive the mime type from the target resource name which should contain the binary (https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/src/main/java/org/apache/sling/testing/mock/sling/loader/ContentLoader.java#L226). This is often useless, as the resource name almost never contains an extension from which a mimetype could be derived (very often a generic name like "file" is used). Instead the first argument (namely classpathResource should be taken as basis to derive the mime type from).
Currently in practically all cases the mime type will be set to the default value (https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/src/main/java/org/apache/sling/testing/mock/sling/loader/ContentLoader.java#L466) which is application/octet-stream.