How to make IntelliJ check and create SerialVersionUID

When the class implements Serializable I want the serialVersionUID field to be auto-created by IntelliJ IDE. This feature comes in automatically in Eclipse. But the former does not.

How do I make IntelliJ create the field or warn me that it is not defined in the class yet?

Database tables map One To Many without foreign key in @JoinColumn

Possible to not have foreign key relationship in child table to its parent in the database, while in JPA it will still be able to map out fine? How will this be done?

Can I still use @JoinColumn to define the field for reference back to the parent table?

This is a one-to-many relationship. One parent record, many child records.

I only care about writes to the database tables right now.


Yes, no FKs defined in the database is fine. JPA will still be able to map out there relationships as defined in your entity classes.

In fact, enabling – spring.jpa.generate-ddl – in your application properties file will create the necessary Foreign Key and/or Unique Key constraints in the database. This is vendor dependent however.

For a One To Many relationship, it is straightforward to do. Example below definition below:

    @OneToMany(cascade = CascadeType.ALL)
    @JoinColumn(name = "recommendation_id")
    private List<CommentEntity> commentList;

This will map out the entity object values to the Comment table, assuming that is the name of the target table. Each one will be persisted to the child table along with the ID of the parent Recomendation under the recommendation_id column.

How to ignore unknown fields when parsing JSON using Jackson

In Java, there is Jackson 2 library that is very popularly used when reading JSON objects and mapping those values out to a POJO.

Happy path, as long a I have all the fields from the JSON defined in the POJO then okay. In a perfect world it will work 100%.

But there is no perfect world. The JSON object in other scenarios can contain unknown fields. These are not in my POJO. Application fails from reading that JSON to POJO.

Getting this error:

Exception in thread "main" com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "status" (class com.example.dto.Evaluation), not marked as ignorable (6 known properties: "Book",


Use this Jackson annotation at a class level. This has to be configured per class. That should do it. Will ignore any unknown properties silently including nested objects.

@JsonIgnoreProperties(ignoreUnknown = true)

When you are using Jackson ObjectMapper directly, that can be configured to ignore unknown properties globally as well.

ObjectMapper objectMapper = new ObjectMapper();
objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);

How Do I Decode An OpenShift Secret In A Mounted Volume?

Mounting an OpenShift Secret to its own volume is straightforward. There are plenty of examples on how to do it. The Web is littered with examples. Next, the most common thing any manual, guide or tutorial would say is to encode the secret in Base64.

For example I have a SSL certificate stored in a Java KeyStore file format or JKS. The recommended way is to store it in a Secret instead of ConfigMap since it is sensitive information. Of course, that goes without saying the JKS file is password-protected.

Second, it must be as a Base64 string before I save it as OpenShift Secret.

How do I get the Base64 string to be decoded in the mounted volume? This one does not seem to get many answers.

Do I need to include shell commands to decode it and write it to a folder?

Which folder should I write it to as best practice?


#1 The encoded JKS Secret as an environment variable

This is an option but I’m not a fan of it. The JKS file when encoded can become very long, especially when the file size is large. I don’t think environment variables were meant to be used like this – hold very long text values. That said, this is an easier implementation.

Map out the secret as an env var in OpenShift or Kubernetes. Then you can use that env var to echo the value and write it out to a file.

echo -n $SECRET_JKS_VAR | base64 --decode > /file/path/to/decoded-secret.jks

#2 Mount for read, mount for write

You have the secret mounted to a file path. That is for reading. Now you need to decode, which means writing to a file so your application can read it back unencoded.

First, define a mount point as and empty directory. It must be writable. Then make it memory only.

Next, read the JKS file from its mount point, write it out to the empty dir mount point.

cat /mount/file/path/for-reading/encoded-secret.jks | base 64 --decode > /mount/file/path/for-writing/decoded-secret.jks

I like this approach better. It makes more sense rather than mapping a very long base64-encoded text value as an environment variable. The caveat is here is slightly more configurations to be made. Also if I’m not mistaken the in-memory volume count against your app memory quota. Should be negligible unless you write thousands of files into it.

#3 Lastly, write where you can

Underneath that container is a file system. Where you have permission to write, then do so there. If it’s Linux, then this decision is pretty much arbitrary IMHO. Put it in /tmp or /home or /mnt. Security wise, others might have access to your app’s pod, that means they can get to the Secret as well. But that is another topic.