The type of binary store used should not influence whether the mime-type is detected or not. As long as Tika is in your classpath and you're using either "content" (default) or "name" and your binary is an nt:resource, the mime type should be detected and set (see modeshape/JcrSession.java at master · ModeShape/modeshape · GitHub
If your binary is not an nt:resource, then it's likely no mime type will be detected.
Well, the nodes in question are simple "nt:file" items, so no cause for issue here.
But from what I could see with a debugger, S3BinaryStore.storeMimeType() is not called -- contrary to S3BinaryStore.getMimeType().
In fact, S3BinaryStore.getMimeType() always returns at least "application/octet-stream", due to S3 default MIME type.
As a result, AbstractBinaryStorage.getMimeType() skips calling the detector: https://github.com/ModeShape/modeshape/blob/master/modeshape-jcr/src/main/java/org/modeshape/jcr/value/binary/AbstractBinaryStore.java#L160
Should I modify S3BinaryStore to return "null" in case of "application/octet-stream", then MIME type detection does work on my machine.
Yes: the S3 binary store should return null if the mimetype for a binary key has not been stored by a prior call to storeMimeType. An exception should only be thrown if mimetype information has been stored, but cannot be read back for some reason.
Please log a JIRA for this as well so we can track it. Thanks.
Hum, but how will it be possible to distinguish between "application/octet-stream" being explicitly set by the user and "application/octet-stream" coming out of S3 by default?
ModeShape will only set a mime-type on the binary property of a node if the jcr:mimeType property does not exist. If a user explicitly sets a mime type (value for this property) ModeShape will never overwrite it.