Since the beginning, we added the capability to upload a logo to visually identify you and your API. In order to support this feature, we designed an interface defining basic operations on the uploaded images: load, save, move and delete.
Thankfully, our FileManager is no longer running like this
Image credit: https://flic.kr/p/4EsmJw
The first implementation was simple and fast to deliver: an abstraction of the local filesystem. This was fine during the development phase, on our laptops. However, it was not possible to scale with this solution as every server would have his own copy of the files locally.
Singleton design pattern on FileManagerFactory, with a single static instance that creates an instance of FileManager based on the class name found in a text file (a Properties configuration file).
In this way, when we create different Tomcat instances, each of them will have a static FileManagerFactory to access the same storage.
While this simple library fits our needs for the project, it may not be the best fit in every case. In case you find it useful, check out the github repo here: https://github.com/Mashape/file-manager
One area of improvement would be using a dependency injection pattern instead of a singleton, or perhaps to avoid the fallback to the default filename ”filemanager.properties” when a getInstance() is called.
If you like this, remember, to fork it!