[ https://issues.apache.org/jira/browse/SLING-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Konrad Windszus updated SLING-6976: ----------------------------------- Summary: ContentLoader.binaryFile() and ContentLoader.binaryResource() should try to derive mimetype from classpath resource rather than from target resource name (was: ContentLoader.binaryFile() and ContentLoader.binaryResource() should try to derive mimetype from classpath resource rather than from target property name) > ContentLoader.binaryFile() and ContentLoader.binaryResource() should try to > derive mimetype from classpath resource rather than from target resource name > --------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: SLING-6976 > URL: https://issues.apache.org/jira/browse/SLING-6976 > Project: Sling > Issue Type: Bug > Components: Testing > Affects Versions: Testing Sling Mock 2.2.12 > Reporter: Konrad Windszus > Attachments: SLING-6976-v01.patch > > > Currently the {{ContentLoader.binaryFile}} tries to derive the mime type from > the target property 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 useless, as the property name almost never contains an extension > from which a mimetype could be derived. 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}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)