Posts

Showing posts from January, 2020

Confusion of terms

At my present assignment I work with a seasoned senior. One of my current tickets will have some impact on the @Controller layer of the application, so I casually stated that I wanted to redo the DTO's (data transfer objects). In the application that I'm working on DTO's are used to transfer data from clients to the application. After which we got into a discussion, which ended up being more a case of miscommunication than an actual arguments. Question marks were put to my idea of adjusting the DTO's. At that moment he thought I wanted to adjust the objects responsible for representing data in our data source (db). Apparently it's also common practice to call these objects DTO's in some applications, especially if you work with a DAO (Data Access Object) pattern. To confuse the matter even further, I said that I didn't want to adjust the models too much. In the application that I was talking about models (also) represent data to be saved in the database....

Flyway or the highway!

Flyway is a great tool to manage the consistency of your database in Java-land.  For each change in the database schema that is needed to run your application consistently with the db, you place a sql file in the db.migration folder. This allows flyway to manage the migration. Flyway checks if the sql files are already executed (using a hash table in the target database), else it will run the neccessary sql script(s). There is however a little setup required, even within a Spring Boot application. You can use the maven flyway plugin to run flyway migrations with mvn over CLI. This would mean decoupling a major part of your database's consistency management from your application into a build script... Though the only thing a Spring Boot application actually needs, is the flyway-core dependency ( which is recommended by Spring ). Keeping the management within the application. Probably the right choice since in this case the db only exists by the authority of that application....

My problem with Cors POST requests

Just encountered a weird "bug" in the CORS protocol. One of my POST request endpoints accepts a multipart form as content type. In local development the front-end sending the request exists on a different origin. Because of the different origin I expected a blocking response to be send though the cross-origin resource sharing mechanism ( cors ) by the back-end managing the endpoint. The back-end is a Spring boot application. Turns out that the back-end fully processed the form data and send back a 200 Ok response... The only thing good thing that happened is that the front-end didn't display the response because of a missing [ Access-Control-Allow-Origin ] header. After reading a clearer guide on CORS that a POST request with a multipart form as content is not blocked through CORS by design... If it was send with a PUT request a proper blocking response would be generated. In my case the request added entities to the database. Not really desirable with data from u...

Tomcat on port 80

My first bug of 2020. Out of habit I tend to run Spring boot web applications on localhost at port 8080 for development. Naively I wanted to change this and run tomcat on my Mac on localhost at port 80, it being a regular http port and all. Result; computer says "NO!" [Caused by: java.net.SocketException: Permission denied].   Turns out port 1024 and lower are generally reserved for users with root access on Unix systems. And to prevent root level code exploits the default http port is 8080 for tomcat.