Perform the following mapping with JPA:
And invoke the following code snippet, whereas papelServico is an EJB abstracting the DAO layer:
This problem only occurs if the permissaoAtribuida properties of class Papel are mapped with cascade =
When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
If the same code runs outside of the Wildfly server context its execution occurs normally.
Apparently the call getEntityManager.().merge(obj) attempts infinite selects to sync the object with transaction context before doing the merge.
Attach the source code of my test classes.
MAC OS Mojave
Wildfly 15.0.1-Final or Wildfly 16.0.0-Final
Data Base Postgresql
I’m having the exact same issue.
The versions we are using are:
Spring Boot: v2.2.0.RELEASE
Our mapping is as follows (changed classnames to prevent production data from leaking out):
@OneToMany (mappedBy = "bookPrimaryKey.student", cascade = CascadeType.ALL, orphanRemoval = true)
private Set<Book> books = new HashSet<>();
private BookPrimaryKey bookPrimaryKey = new BookPrimaryKey();
BookPrimaryKey.java (has @Embeddable. Next to the student field this primary key class also has 2 other fields that are used as composite ID, one of those fields is a custom value type for dates which can not be used in @Idclass because of serialization issues, so switching from @Embeddable to @Idclass is sadly not a solution for us)
@ManyToOne (fetch = FetchType.LAZY)
@JoinColumn (name = "student_id", nullable = false, insertable = false, updatable = false)
private Student student;
The problem is that the book tries to load the student, and the student tries to load the list of books (even though FetchType.LAZY is on there), introducing an infinite loop.
An interesting observation we made is that whenever we delete the target directory (we use QueryDSL to generate JPA queries), then run mvn clean process-resources, the issue does not occur.
However, as soon as we add mvn package to the pipeline, the Stackoverflow error as described by OP occurs.
Same story for mvn clean install.
So it looks like somewhere in the package step something happens that introduces this issue.