Mailing-List: contact dev-help@sling.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@sling.apache.org
Date: Wed, 21 Jun 2017 12:55:00 +0000 (UTC)
From: "Konrad Windszus (JIRA)" <jira@apache.org>
To: dev@sling.apache.org
Message-ID: <JIRA.13081409.1498048779000.69279.1498049700104@Atlassian.JIRA>
In-Reply-To: <JIRA.13081409.1498048779000@Atlassian.JIRA>
References: <JIRA.13081409.1498048779000@Atlassian.JIRA> <JIRA.13081409.1498048779107@jira-lw-us.apache.org>
Subject: [jira] [Updated] (SLING-6976) ContentLoader.binaryFile() and
 ContentLoader.binaryResource() should try to derive mimetype from classpath
 resource rather than from target resource name
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 21 Jun 2017 12:55:11 -0000


     [ https://issues.apache.org/jira/browse/SLING-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Konrad Windszus updated SLING-6976:
-----------------------------------
    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}}.

  was:
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}}.


> 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 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}}.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)