Challenge Overview
As part of the roll out of the new submission system, we want to stop using NFS and gradually migrate to AWS S3 as the repository for all files related with submissions, therefore we need to modify the submission processor and make sure all files that are uploaded, modified and generated are stored in S3 as part of the submission processing.
We also want to CONTINUE saving files to NFS, so that legacy applications can continue to find and download those files. This functionality is already implemented in the submission processor and should not be changed.
Currently the initial files that are uploaded by the members creating a submission are saved in S3, then the submission processor downloads those submission files, generates a unified zip, generates images with alternate sizes, and watermarked images. The only file that is saved back to S3 is the unified zip, however the unified zip is saved in a different folder than the submission, and we want to change that.
The File Service is used to upload and download files to S3. We provide a mocked file service that can be used to simulate what the File Service and S3 do.
The initial upload that is performed by the users is uploaded to:
submissions/{dynamodb-submission-id}/
Preview file (image: png or jpg);
Submission zip;
Source zip;
And once the unified submission zip is generated, it is uploaded to:
submissions/{informix-challenge-id}/{user handle}_{user id}/{timestamp}.zip
The first task of this challenge is to change the upload destination of the unified submission zip to:
submissions/{dynamodb-submission-id}/unified.zip
This action happens inside the S3UploadProcessor.java
The second task of this challenge is to upload images generated by the process, which mostly happen in the WatermarkProcessor.java, into the following folder in S3:
submissions/{dynamodb-submission-id}/images/{filename}.{ext}
Note, the processor was engineered using a chain of responsibility pattern, in which each Processor class is very specific in the task it performs. Changes to the code must follow this pattern, for instance, uploads to S3 must not happen inside the WatermarkProcessor class, but they could happen inside the S3UploadProcessor class.
It is fine to change the sequence of processors as long as no functionality is broken or lost.
About Development Environment
We have provided a guide to setup the local environment in Linux, and we are still working on the setup guide for Mac OS and Windows. Please check the attached submission-system.zip for setup and base source code to change.
Final Submission Guidelines
1. Code Changes for the requirements.2. Updated Setup Guide if any
3. Verification Steps for the changes.