2

Our project is a Spring Boot 2.7 project with a dependency on spring-boot-starter-data-jpa, lombok, MapStruct and other libraries. Building the project with (Maven 3.6.2, JDK 17.0.2)

mvn clean package -Pdevelopment

produces a .war file which, when deployed to Tomcat 9.0.64, throws under certain conditions the following exception

org.springframework.dao.InvalidDataAccessApiUsageException: org.hibernate.TransientPropertyValueException: object references an unsaved transient instance - save the transient instance before flushing

This same project, when built and deployed to the same Tomcat by IntelliJ (in the most straightforward way), does not, under the same conditions, throw this exception.

Comparing the binary files in the two .war files, I see, for instance, that all these $$_hibernate_read, $$_hibernate_write, present in a .class file from the .war file generated by mvn package:

enter image description here

are completely absent in the corresponding .class file from the .war file generated by the default build process of IntelliJ. I did not have much success in understanding what is this default build process precisely, but at least it uses the same Java version, the image of the build process in Process Explorer being something like:

D:\jvm\jdk-17.0.2\bin\java.exe -Xmx700m ......... D:/IntelliJ IDEA 2022.2/plugins/ant/lib/ant-jps.jar;D:/IntelliJ IDEA 2022.2/plugins/maven/lib/maven-jps.jar;D:/IntelliJ IDEA 2022.2/plugins/gradle-java/lib/gradle-jps.jar;D:/IntelliJ IDEA 2022.2/plugins/JPA/lib/jps/javaee-jpa-jps.jar" org.jetbrains.jps.cmdline.BuildMain 127.0.0.1 64013 5bf45946-3060-4d79-96c2-8e1a83c92574 C:/Users/..../AppData/Local/JetBrains/IntelliJIdea2022.2/compile-server

The error org.springframework.dao.InvalidDataAccessApiUsageException by itself does not worry me very much, but the behavior is quite bothering since this means that I cannot really trust IntelliJ to catch such errors, and I really should deploy and test related features on Tomcat manually before releasing them.

Can I configure the IntelliJ build process so that it produces the .war artifact by running "mvn clean package" instead of its custom build process? Or perhaps I am just doing something in a wrong way?

abor igen
  • 21
  • 3
  • 1
    Please copy/paste text here as text rather than an image. – Code-Apprentice Jul 19 '23 at 16:16
  • it's a binary file with a lot of special characters, I pasted an image instead – abor igen Jul 19 '23 at 16:23
  • The red circle in your image surrounds text that could be copy/pasted. – Code-Apprentice Jul 19 '23 at 16:53
  • First Maven 3.6.2 is a bit out of date...most recent version, IntelliJ is also a bit out of date... and also spring boot 2.7.X might be a good time in point to upgrade those things... – khmarbaise Jul 19 '23 at 21:11
  • 1
    Does the issue persist with the latest (2023.1.4) version of IDEA? Are you building the Project in IDEA by running "package" Lifecycle from the Maven Tool Window? Can you share IDEA's Maven configuration "Settings/Preferences -> Build, Execution, Deployment -> Build Tools -> Maven" and "Settings/Preferences -> Build, Execution, Deployment -> Build Tools -> Maven -> Runner"? – romanv-jb Jul 20 '23 at 13:21
  • I would say based on the issue: `object references an unsaved transient instance - save the transient instance before flushing`. your application has some problems... – khmarbaise Jul 21 '23 at 07:22
  • @khmarbaise in fact, we did not really understand where this error came from, because the code, upon inspection, looked ok. After a colleague of mine has put @Transactional(readOnly = true) on the method which produced the error and @OneToOne(fetch = FetchType.EAGER) instead of LAZY on one of the fields made the error go away. But to me this indeed looks suspicious, so could you perhaps expand on "your application has some problems"? – abor igen Jul 21 '23 at 09:55
  • If you define an attribute transient it means it will not being persisted... that seemed to be the issue... – khmarbaise Jul 21 '23 at 10:03
  • @khmarbaise maybe I misunderstand what you say, but there were no '@Transient' fields.. and the error was happening upon just reading an entity (and mapstruct-ing it to dto). – abor igen Jul 21 '23 at 10:18
  • Transient is not only an annotation (https://stackoverflow.com/questions/910374/why-does-java-have-transient-fields) ... `save the transient instance before flushing` and obviously there is one somewhere... based on the stack trace output... – khmarbaise Jul 21 '23 at 10:29
  • @khmarbaise not sure I am following you.. the link you posted points to Java transient fields, which should be a different notion, not related to Hibernate errors. – abor igen Jul 21 '23 at 10:59
  • @romanv-jb thank you, this is what I was looking for. Indeed, under Build Tools > Maven > Runner one may check the option "Delegate IDE build/run actions to Maven", and then the error comes out, since the .war is built now by Maven instead of IntelliJ (though not directly through launching mvn). If you would like, post an answer, and I will accept it. – abor igen Jul 21 '23 at 11:03
  • @abor igen I'm glad I could help, though IDEA's Runner was designed to generate results identical to Maven. I would really appreciate if you could test if the issue still persists in the latest version of IDEA (2023.1.4), because if so, this may require further investigation. – romanv-jb Jul 21 '23 at 12:05
  • @romanv-jb just tried it with IntelliJ 2023.1.4, the issue is still there (if the option "Delegate IDE build/run actions to Maven" is unchecked, no error comes out, if it is checked, the error is there). – abor igen Jul 21 '23 at 12:51
  • @romanv-jb the application error turned out to be due to one of the fields of an entity being initialized as myField=new AnotherEntity(), which, quite obvioiusly, should cause the 'save the transient instance before flushing' error after the transaction commits. Perhaps the building process of IntelliJ somehow missed this field initialization? There are lombok annotations on the original entity class, maybe that has to do with it, but I did not try to look further. – abor igen Jul 24 '23 at 12:08

0 Answers0