Solon File Upload: UploadedFile Over MultipartFile Explained
Discover how the Solon framework handles file uploads using UploadedFile, offering explicit control and transparency without heavy auto-configurations.
Stock photo for illustration only, not from the actual event
- Solon uses the UploadedFile core class in the web layer with zero extra configuration.
- The framework does not auto-clean temp files, making the try/finally pattern mandatory.
- Supports multiple files via UploadedFile[] arrays since version v2.3.8.
- Fine-tune body sizes and memory thresholds easily via app.yml settings like fileSizeThreshold in v3.6.0.
File uploading often feels mundane until you spend an entire afternoon debugging a MultipartException: Failed to parse multipart servlet request in a production environment. In Spring Boot, handling file uploads involves numerous components such as MultipartFile, MultipartAutoConfiguration, spring.servlet.multipart.* properties, alongside a quiet assumption that your application runs on a servlet container. While it functions well, it carries a substantial amount of hidden machinery behind the scenes.
Solon takes a completely different path. Its core class is UploadedFile, residing natively in the web layer without requiring any extra configuration. This design provides developers with explicit control over when multipart parsing occurs and precisely when temporary files are cleaned up.
Stock photo for illustration only, not from the actual event
Whenever a controller method includes an UploadedFile parameter, Solon automatically triggers multipart parsing without requiring any explicit annotations. Common implementation patterns include:
- Single file parameter: @Param("user_avatar") UploadedFile file handling the form field "user_avatar"
- Multiple files: Utilizing UploadedFile[] when clients submit multiple files under an identical field name (supported since v2.3.8)
- Mixed forms: Receiving both file and regular text fields concurrently within the same request
One critical detail to note is that the framework does not automatically clean up temporary files. If you omit the delete() call, those temporary files will remain stored on your disk. Consequently, incorporating the try/finally pattern is mandatory rather than optional.
Requiring developers to handle temporary file deletion explicitly via try/finally highlights Solon's philosophy of avoiding hidden magic. By bringing disk I/O and resource lifecycle management directly into the developer's field of view, it prevents unexpected disk space leaks in production environments compared to frameworks that abstract these details away entirely.
To manage request payloads and memory thresholds efficiently, configurations can be specified directly inside the app.yml file:
- server.request.maxBodySize: Maximum request body size (default: 2mb)
- server.request.maxFileSize: Maximum single file upload size (default: 20mb)
- server.request.maxHeaderSize: Maximum header size limit (8kb)
- server.request.fileSizeThreshold: Files below this threshold route to memory, while larger files route to disk (introduced in v3.6.0)
The fileSizeThreshold setting introduced in v3.6.0 automatically routes small files directly to memory and large files to disk. Prior to version v3.6.0, developers had to rely on useTempfile: true to force temporary file mode—a flag that has now been officially deprecated.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment