You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a class with a constraint on attachment contentType which includes docx (application/vnd.openxmlformats-officedocument.wordprocessingml.document). That works perfectly fine when creating instances but updating instances fails because contentType is suddenly "application/octet-stream". The file is stored in the local file system.
I had a look into the selfie code and I think I understand the problem but I'm not sure how to fix it:
When creating, the contentType of the uploaded file is determined by this line of code. The file object is an instance of org.springframework.web.multipart.MultipartFile (or org.springframework.web.multipart.commons.CommonsMultipartFile in older versions of selfie), which returns the correct content type for docx.
However, when updating, the content type is determined by this line of code. In this case the getContentType method of Karman's LocalCloudFile class is used and eventually returns a lookup in this map where in fact docx is missing.
So I think this is a two part problem:
selfie should use the same methods for content type determination on safe and on update in order to achieve consistent behaviour.
I have a class with a constraint on attachment contentType which includes docx (application/vnd.openxmlformats-officedocument.wordprocessingml.document). That works perfectly fine when creating instances but updating instances fails because contentType is suddenly "application/octet-stream". The file is stored in the local file system.
I had a look into the selfie code and I think I understand the problem but I'm not sure how to fix it:
When creating, the contentType of the uploaded file is determined by this line of code. The file object is an instance of org.springframework.web.multipart.MultipartFile (or org.springframework.web.multipart.commons.CommonsMultipartFile in older versions of selfie), which returns the correct content type for docx.
However, when updating, the content type is determined by this line of code. In this case the getContentType method of Karman's LocalCloudFile class is used and eventually returns a lookup in this map where in fact docx is missing.
So I think this is a two part problem:
PS: I contributed a fix for a similar problem in selfie some time ago which I now think should actually have been applied at the root of the problem
The text was updated successfully, but these errors were encountered: