Spring and Spring Boot (Java EE) Software Development

Accessing the Spring H2 database console when X-Frame-Options says deny

(Fri Jan 05 2018 00:00:00 GMT+0200 (Eastern European Standard Time))

You're coding a Spring Boot application, need a database, and quickly configure in the H2 in-memory database thinking it'll be easy. Rerun the application, do a few things, then try to get into the H2 console, and it's a blank screen. The JavaScript console says "Refused to display ... in a frame because it set 'X-Frame-Options' to 'deny'." and there's a sinking feeling, it's another one of those obtuse error messages from the bowels of somewhere you've never heard of. Fortunately the solution is easy.

Solving Http Message NotWritable Exception, Could not write JSON: Could not set field value in Spring Boot

(Mon Oct 16 2017 00:00:00 GMT+0300 (Eastern European Summer Time)) My experience of programming on the Spring platform is that you'll be coding along, everything is going great, until an inscrutable complex error message emerges from the depths of who knows where. This message seemed to involve some module or another having created a round peg to fit into a square hole. That is, I'd sent a GET request to retrieve a large object tree, and it seemed that while filling data into a field of a subsidiary object Spring/Hibernate/etc chose the wrong data type, and it threw up an error. The specific type of error was receiving no discussion anywhere, so it was impossible to see how others had solved the problem. The documentation was of no use in explaining anything about this. But, after a couple days of trials and errors and more errors, a solution was found. And, indeed, Spring/Hibernate had chosen the wrong data type to fill into one of the fields, and the solution is fairly simple.

Persisting complex Embeddable/Embedded objects in Spring/Hibernate

(Sun Oct 08 2017 00:00:00 GMT+0300 (Eastern European Summer Time)) Hibernate and Spring and the Java Persistence packages make for a powerful combination. You can define a complex tree of objects, and the system automagically creates the database schema, and automagically saves and retrieves that object tree from the database. It means you can innocently code away, until one day you try to include an Embedded object but it silently fails to be saved to the database, Hibernate silently fails to create database columns for that object, and when retrieving the object for which the Embedded object is a field, the object is null. No error messages are printed in the log. Instead you're left wondering, why didn't Hibernate persist this object? What's presented here is a solution using EntityListener methods to convert values in and out of shadow values stored in the Entity.

A fix for "Persistent Object Exception - detached entity passed to persist" in Spring Boot

(Wed Sep 06 2017 00:00:00 GMT+0300 (Eastern European Summer Time)) Error messages coming out of Spring can be more than inscrutable. As discussed in my solution to transient unsaved properties, I'm defining a REST API using Swagger/OpenAPI targeting a Spring Boot implementation. The object models are complex, with lots of nested objects. Today's inscrutable message, "detached entity passed to persist", doesn't make much sense as a phrase does it? Detached? Detached Entity? Say what? Turns out it's not that hard a problem to fix.

A fix for org hibernate TransientPropertyValueException in Spring Boot

(Fri Sep 01 2017 00:00:00 GMT+0300 (Eastern European Summer Time))

Error messages coming out of Spring can be more than inscrutable. In this case I'm defining a REST API using Swagger/OpenAPI targeting a Spring Boot implementation. The object models are complex, with lots of nested objects. It turns out you can POST a big blob of JSON with all kinds of structure, and Spring/JPA/Hibernate will swallow the whole thing and automatically parcel everything out to the corresponding database table. If you define the JPA annotations correctly, that is.

Get an annotation incorrect, and you'll be left scratching your head over what the heck you're being told by the error message. The Spring Team promises on a huge stack of bibles that Spring Boot automatically takes care of zillions of things for you, and it's so easy to write your code. In my experience it's instead a matter of papering complexity over complexity over a system containing about a thousand kitchen sinks worth of excess capabilities. There's no amount of papering-over that kind of complexity that will make the system simpler. But, the boss-man says to use Spring Boot, so here goes.