The Sqreen project was difficult from the very beginning. This Content Management System (CMS) was written from the ground up at the end of 2014. It used Spring version 3.2.1 which was released roughly in December 2011, and Java 6, which was EOL by April 2013. We started work on this project in August of 2018 and as you can see, this already old system is using essentially ancient dependencies and technologies which are not only difficult to find resources for online, but also generally less feature-rich than one would hope in a modern application. The server it ran on used Jboss 7.1 and ran Java 7 because presumably finding Java 6 was impossible by this time even though the application used 6 as its language level. As you will see, we encountered many pitfalls in the development process due to the severe obsolescence of the product.
To begin with, finding the correct server versions and technologies required days of searching for the correct packages online but eventually we finally got a test server running with the original .war file. We thought it would be smooth sailing from there but as it turns out, that wasn’t meant to be. Testing on the server was excruciatingly slow (obviously, it was only running on a cloud server, not in our IDE), and eventually it stopped deploying to this server altogether. We reverted the code back to the original and it still wouldn’t deploy. Confused, I decided to take this time to finally get it running locally, and did so using Tomcat 8, and some magical version of Java 7 that took me 4 hours to find in 2018. Alas, using this local setup was much more stable and we were able to finish much of the development using just this setup.
When the changes were finalised and we had to bring the application onto the live server, all the previous issues caught up with us. Deploying it didn’t work and we couldn’t understand why. As it turns out, when using Maven to package a .war file, you have to clean in between each package. If you don’t do this, you’ll get the problem we got, where Jboss refused to deploy the war file due to duplicate packages in the target folder. Tomcat on the other hand was more resilient and deployed no matter what. Lesson: Always clean before packaging.