quarkus-bot[bot]
commented
2 years ago /cc @evanchooly, @stuartwdouglas
Open languitar opened 2 years ago
quarkus-bot[bot]
commented
2 years ago /cc @evanchooly, @stuartwdouglas
quarkus-bot[bot]
commented
2 years ago You added a link to a Zulip discussion, please make sure the description of the issue is comprehensive and doesn't require accessing Zulip.
This message is automatically generated by a bot.
stuartwdouglas
commented
2 years ago Where does the JPA plugin come from? If you use the no-arg plugin and set <option>no-arg:annotation=javax.persistence.Entity</option> I see this working fine.
stuartwdouglas
commented
2 years ago Ok, so it looks like somehow when it sees the 'jpa' plugin it maps it to no-arg with specific parameters, it seems like we don't take these presets into account: https://github.com/JetBrains/kotlin/blob/master/plugins/noarg/noarg-cli/src/NoArgPlugin.kt#L53
stuartwdouglas
commented
2 years ago Also note that this applies to dev mode in general, its not really continuous testing related.
languitar
commented
2 years ago So, as there already is something like the jpa preset in the code, that doesn't trigger because the no-arg plugin is not in the compiler plugin list? Or what is the bug here?
stuartwdouglas
commented
2 years ago Something in our code basically does not handle presets, only the plugin + parameters form. I had a quick look but it was not really obvious what was missing. As a workaround you can use no-arg directly and just list the annotations.
@Sanne on a semi related note, what do you think about having Quarkus automatically add no-arg constructors to JPA entities if it is missing?
languitar
commented
2 years ago Thank you for the explanations! We'll try that.
Sanne
commented
2 years ago @Sanne on a semi related note, what do you think about having Quarkus automatically add no-arg constructors to JPA entities if it is missing?
I'm skeptical - if the default constructor is missing, it implies another one was added explicitly - most likely to initialize some state - which the user then expects to be initialized. I doubt people add unnecessary constructors for fun. How would you handle that?
In particular, can you guarantee we produce valid bytecode if there's final fields that require initialization?
I tend to prefer making the error explicit and let the user deal with it. Unless you have some idea to safely identify an "obvious and straight forward" case, such as someone adding a new convenience constructor - that yes could be interesting, if done carefully.
If we go to such lenght, we might be better off to generate an implementation of the Hibernate's Instantiator SPI - same effect for the user, but slightly more efficient codepath at runtime.
stuartwdouglas
commented
2 years ago The use case I was thinking of primarily was the kotlin one: https://github.com/languitar/kotlin-panache-reload-issue/blob/main/src/main/kotlin/org/acme/TestEntity.kt#L10
Also I am pretty sure there are lots of entities out there that only have a default constructor because hibernate requires it.
In terms of final fields I would just disable the feature for entities that had final fields.
Sanne
commented
2 years ago In terms of final fields I would just disable the feature for entities that had final fields.
OK yes in that case it sounds good.
MartinX3
commented
2 years ago Still happening randomly in 2.6.2.
I think if I modify a class while hotreloading and somehow the bytecode gets corrupted?
Doing a gradle clean is the only way to fix it. A simply restart of the dev mode doesn't work.
geoand
commented
2 years ago @glefloch I assume this is / will be handled by the changes you made recently?
glefloch
commented
2 years ago I will give it a try and update the issue
andreas-eberle
commented
1 year ago Unfortunately, the issue still seems to exist in version 3.2.2.Final. Are there any updates? Could a new reproducer help you debug it?
mschorsch
commented
9 months ago For gradle i've found the following workaround: https://github.com/quarkusio/quarkus/issues/37109#issuecomment-1828352002. Maybe this could be a starter?
I could imagine that something like this could work for maven (untested):
<dependencies>
<dependency>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-noarg-compiler-plugin</artifactId>
<version>1.9.10</version>
</dependency>
</dependencies>
<plugin>
<groupId>${quarkus.platform.group-id}</groupId>
<artifactId>quarkus-maven-plugin</artifactId>
<version>${quarkus.platform.version}</version>
<configuration>
<compilerOptions>
<compiler>
<name>kotlin</name>
<args>
<arg>-Xplugin=${System.getProperty("user.home")/.m2/repository/org/jetbrains/kotlin/kotlin-noarg-compiler-plugin/1.9.10/kotlin-noarg-compiler-plugin-1.9.10.jar}</arg>
<arg>-P=plugin:org.jetbrains.kotlin.noarg:preset=jpa</arg>
<!-- <arg>-P=plugin:org.jetbrains.kotlin.noarg:annotation=com.my.Annotation</arg> -->
</args>
</compiler>
</compilerOptions>
</configuration>
</plugin>Links:
Describe the bug
In a Kotlin project that uses the no-arg / jpa Kotlin compiler plugin, entities cannot be changed in continuous testing mode because the compiler plugin is not used when the affected entity class is recompiled on demand. As a result, tests the fail due to a missing no-arguments constructor.
Expected behavior
Entites can be changed just as any other code and tests simply continue to work.
Actual behavior
How to Reproduce?
https://github.com/languitar/kotlin-panache-reload-issue contains a project to start with
mvn quarkus:devr- tests will execute successfullyTestEntity.ktuncomment the line containinguncommentToTriggerBugand save the fileTests will re-execute and fail.
Output of
uname -aorverLinux bird 5.14.16-arch1-1 #1 SMP PREEMPT Tue, 02 Nov 2021 22:22:59 +0000 x86_64 GNU/Linux
Output of
java -versionopenjdk version "11.0.13" 2021-10-19
GraalVM version (if different from Java)
No response
Quarkus version or git rev
as in project
Build tool (ie. output of
mvnw --versionorgradlew --version)Maven 3.8.3
Additional information
Initially discussed in Zulip: https://quarkusio.zulipchat.com/#narrow/stream/187030-users/topic/Continuous.20testing.20with.20kotlin.20compiler.20plugins