Use Java 1.6+ MimeTypesFiletypeMap for SimpleStorageResource content type derivation

[chrisrhut]

Type: Feature

Is your feature request related to a problem? Please describe.
We would like to be able to take advantage of this library's WritableResource creation by just using a s3:// URL. Unfortunately there's not quite enough flexibility in determining the content type. The code in SimpleStorageNameUtils makes a call to URLConnection#guessContentTypeFromName() which is difficult to extend.

As a result, we have to manually create and upload using AmazonS3 (or TransferManager).

As of Java 1.6, there is a facility called MimeTypesFiletypeMap which is similar but somewhat easier to customize. Any META-INF/mime.types file in your app classpath can augment the default types, and provide a mapping from file extension to content type.

This proposal is to augment (if not replace) the URLConnection call to make it easier to use user-defined mappings.

Describe the solution you'd like
Something like:

static String getContentTypeFromLocation(String location) {
    String objectName = getObjectNameFromLocation(location);
    if (StringUtils.hasLength(objectName)) {
      String contentType = FileTypeMap.getDefaultFileTypeMap().getContentType(objectName);
      if (contentType == null) {
        contentType = URLConnection.guessContentTypeFromName(objectName);
      }

      return contentType;
    }
    return null;
}

Additional context
The FileTypeMap is in javax.activation API, which does seem to be included as a dependency for this project.

Assuming you agree with the general premise, I'd be happy to put together a PR for this.

[maciejwalkowiak]

Thanks @chrisrhut for suggestion and apologies for late reply. I like this idea if especially if we make it in a backward compatible way - so that we don't break existing users - and also if we make using javax.activation API optional. Checking for class presence can be done with Spring ClassUtils.isPresent(..). You have green light for preparing a PR 👍

[chrisrhut]

Hi @maciejwalkowiak, thanks for the reply and no worries on the delay!

Unfortunately the default behavior changes in a non-extensible way: the javax.activation.MimeTypesFiletypeMap falls back to application/octet-stream - rather than null - if there's no match, and there's no way to modify this behavior.

My suspicion is that ultimately this would be fine, since any store such as s3 would just use default handling if null is passed as the type and application/octet-stream is as generic as it gets.

However, the fact that this immediately failed the unit tests gives me pause. What do you think, should we 86 this idea?

[maciejwalkowiak]

In 3.0 we will still rely on guessContentTypeFromName but will give an option to provide custom implementation of content type resolver. This is because we still need to support Java 8+, and there was quite a bit of mess with javax.activation that I don't think i want to solve now.

Anyways, you won't be limited anymore to the content type resolution provided by the framework and i think this is a good middleground.