Project cleanup + Proper Spring Boot setup + general docker integration

[emschu]

I started to get the most recent version of MBP to work locally and ran into a lot of problems. This is about how it started, because I didn't intend to modernize and clean up (a little) the project firstly... But I think there is a chance that you might find these fixes, changes and updates helpful :)

At first I just wanted to make a proper docker(-compose) build for testing and (potential) development purposes, because I have to rely on this project in the university context. Looking at the code and the installation routine I found the self-made Tomcat-deployment-solution which is really not required here, because Spring Boot is already able to build a "fat jar" containing a (well-configured) Tomcat servlet container for the application. There is also a lot of boilerplate code which is really not necessary to get this project to work. I thought I could do the changes quickly and move on, but I had to solve different problems to get the app working both locally during development and deployed in a docker container. So I fixed the problems keeping in mind you could appreciate a proper project setup too.

To get the project to work with docker(-compose), one needs to execute the following commands on this branch:

make clean package -DskipTests=true
docker-compose build
docker-compose up

Visit: 127.0.0.1:8080/mbp

That's it.

The mbp service in the docker-compose.yml can be commented out to have a working development environment with MongoDB + Custom Mosquitto and the IDE could start the app. Also useful for unit tests.

This PR contains:

• A general update to Spring Boot 2.6.1 and a proper and recommended Spring Boot app setup
• Removing the most obvious not required boilerplate code
• Fixes of at least 5 memory leaks
• There is no longer a .war file created, but a MBP.jar and the corresponding (complicated) maven plugin section is removed, because the spring-boot-maven-plugin already does all this and more
• Consistently using spring properties feature and no longer self-made solutions, e.g. config.properties, PropertySourcesConfiguration
• Servlet context path has changed from /MBP to /mbp
• Spring Boot Actuator is part of the pom.xml which makes development sometimes a lot easier + providing detailled app's health information
• A lot of migrations because of deprecations, e.g. new EntityModel() -> EntityModel.of()
• Full development support for docker out-of-the-box. No more installation scripts are required which only work on Debian/Ubuntu based linux systems. The solution proposed in this PR should work an Windows, Unix and Linux systems.
• Spring Boot ships with a profile feature to load different properties for different profiles defined at runtime. This makes it easy to use the same .jar in development, in docker and in "prod" environment with proper default values.
  • There are two profiles for now: dev and docker. You should use dev during local development.
• The existing custom mosquitto image build process containing an optional custom plugin is still being used, depending on the value of is_secure build argument in the docker-compose.yml file. true means the mosquitto container is shipped with the plugin binary as well.
• pom.xml is cleaned up
• Copy: /src/main/webapp -> /src/main/resources/templates (spring boot default location for templates)
• The frontend code is unchanged except two code places where WEB-INF was a hardcoded path.

Notes:

• There are a lot of code places where Exceptions are swallowed, ignored or are too generic, e.g. catch(Exception ex){}. This makes it really hard to debug the application if something fails.
• There is very little logging in general - why? Logs are a friend of us and help a lot. Disabling them is always possible..
• The DynamicBeanProvider is evil and can cause very confusing bugs (I found at least one), because Spring wants you to use Dependency Injection.
• Please read the Spring (Boot) Framework documentation
• There are multiple circular dependencies of services which is pretty discouraged. The @Lazy annotation should avoid problems with these code places.
• There are a lot of problems with null-safety..
• The implemented security mechanism is not battleproof and there are hard coded passwords... I hope this software is not running on a server in the internet... Before deploying this software anywhere in the wild, this project clearly needs auditing and/or pentests. So long I would consider this project harmful, because there is just too much unfiltered/untrusted user input.
• I hope these changes are improving your developer experience and make it more easy to get familiar with the project.
• I'm using JDK 11 for development and as runtime environment in this PR
• Unit Tests work

Issues:

• I could not properly test the OAuth2 Flow, because in the requestOAuth2Token()-method returns 401. This should be investigated.

It would be great to receive your honest feedback on this - unfortunately pretty big - PR. Please let me know what you think about these changes.

[emschu]

Thank you very much for looking into this PR, providing feedback and integrating most of its changes.

Servlet context path has changed from /MBP to /mbp

Is there a certain reason why this was necessary? While it may force some of the project developers to adapt their local development environments accordingly, for me this change is fine.

No, this change is not really necessary, but it will most certainly cause effects in depending projects, which rely on the uppercase variant. I want to let you decide if this change is helpful.

[schneijan]

Thanks a lot!