-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrading to 2.14 breaks REST resources (potentially because of BeanParam) #29227
Comments
What is interesting, is this is the first failure in a test that almost does nothing... @Disabled
@QuarkusTest
@Tag("functional")
public class ArtifactParamTest {
@Test
void should_have_all_args() {
ArtifactParams params = new ArtifactParams();
params.setClient("a");
params.setProject("b");
params.setArtifact("c");
assertNotNull(params.getClient());
assertNotNull(params.getProject());
assertNotNull(params.getArtifact());
} Giving this error:
These are the classes: @Data
@NoArgsConstructor
@EqualsAndHashCode(callSuper = true)
public class ArtifactParams extends ProjectParams {
@PathParam("artifact")
private String artifact;
public ArtifactParams(final String artifact, final String project, final String client) {
super(project, client);
this.artifact = artifact;
}
} @Data
@NoArgsConstructor
@EqualsAndHashCode(callSuper = true)
public class ProjectParams extends ClientParams {
@PathParam("project")
private String project;
public ProjectParams(final String project, final String client) {
super(client);
this.project = project;
}
} @Data
public class AssetParams extends ProjectParams {
@PathParam("filename")
private String filename;
@PathParam("ext")
private String ext;
@JsonIgnore
public final String getFilename() {
return filename + '.' + ext;
}
} |
I may of found one of the issues when "just building" - have
For example: changing everywhere (basically remove @BeanParam completely) looks to work. Uni<Client> locate(@BeanParam ClientParams params); to this Uni<Client> locate(ClientParams params); I verified that is was @BeanParam "somewhere" by reverting and building (failed) then globally removing it and building (passed). |
I decided to start over because I was getting lost in what I was testing. I still cannot reproduce it with a simple reproducer but I can verify that flip-flopping back and forth either resolve/brings back the issues...
Here is where it get weird:
In the REST client with Uni<Feature> save(final Feature feature, final ClientParams params); I just picked the first place the errors happened and extends one of the Params or as I found out later added a dummy @Data
@RegisterForReflection
@EqualsAndHashCode(onlyExplicitlyIncluded = true)
public class Feature extends ClientParams{ I can verify that:
It may have something to do with (where I am at now):
Summary of problems:
|
I cobbled the hec out of the projects to try and get you a reproducer. Hopefully this helps. In all case, just running Working as-is with 2.13.4 Here is the "ambiguous" bean error and then after removing Hopefully this helps pinpoint the issue... |
/cc @FroMage, @geoand, @stuartwdouglas |
@FroMage This looks like it could be due to the changes made to unify |
Sure. |
🙏🏼 |
I think this has to do with getters not being supported by bean params, but I'm pretty sure I didn't remove that, we talked about it: I think this was never implemented. So let's dig in. |
Oh wait, this is client, not server. |
If it adds to the conversation, I removed all occurrences of @BeanParam and got rid of POST/PUT methods specifically in the REST clients and was able to get it working (or at least I think it did - tests passed and REST smoke tests worked). For whatever reason it seems to throw the exceptions on those (# 1 above). |
The ambiguous resolution is lying to us: it's not a client bug, but a server bug. The client is fine with it. It only happens in your reproducer because the server picks up some client interfaces and creates a deployment. Not sure why yet, because I can't reproduce it outside of your project yet. |
Hah, that makes me feel better. I tried creating a simple reproducer (all day) at first using my standard template and I could not reproduce it. The only I could replicate it was to take our entire project, gut it, and then try... |
Curious if you have had any luck with this since we are putting together a plan to either hold-off or remove all use of @BeanParams because it is starting to cause us other issues downstream. |
I'm still working on this, but I'm juggling other priorities as well. |
I think I've a fix for the "ambiguous" error. But I don't quite know how to trigger the second from your source code, which is using Lombok and should just keep the annotations on the fields, even with the properties accessors generated |
We don't support bean params with annotations on the accessors, but it doesn't seem to be your case. |
Would you be willing to build Quarkus from sources with my fix to verify that it works for you? |
Absolutely. And no rush - we just need to put a mitigation plan together
on on end.
…On Fri, Nov 18, 2022 at 10:30 AM Stéphane Épardaud ***@***.***> wrote:
Would you be willing to build Quarkus from sources with my fix to verify
that it works for you?
—
Reply to this email directly, view it on GitHub
<#29227 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAECKMTM7EP67CVKB4PG5NLWI6OLFANCNFSM6AAAAAAR6LF6SA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
*KimJohn ***@***.*** ***@***.***>*
*Logicdrop**O* 888.229.2817
*M* 248.882.0728
*www.logicdrop.com <http://www.logicdrop.com/>*
|
OK, so, can you try #29355 ? Thanks! |
Yes, I will give it a try tonight/this weekend and let you know...
…On Fri, Nov 18, 2022 at 11:02 AM Stéphane Épardaud ***@***.***> wrote:
OK, so, can you try #29355
<#29355> ? Thanks!
—
Reply to this email directly, view it on GitHub
<#29227 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAECKMRB6CS3HUQMMP2Q2SDWI6SABANCNFSM6AAAAAAR6LF6SA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
*KimJohn ***@***.*** ***@***.***>*
*Logicdrop**O* 888.229.2817
*M* 248.882.0728
*www.logicdrop.com <http://www.logicdrop.com/>*
|
Quick update, I finally got your fork/ref to compile (had to disable gradle for some reason), and I can match up your changes... At a quick pass, it seems to compile with Looks like progress though ;) |
I think I found it, or at least the cause. Once we got past the ambiguous bean compilation error it seem to have nothing more to do with that. What I realized was that only methods referencing a specific bean was causing the problems. Didn't matter if it came from a RESTClient, had a @BeanParam or not, just annotating it as a REST method, Lombok or not - they all failed. The failure was the same in all cases and specific to the a single payload. If I took that payload out everything worked. quarkus.builder.BuildException: Build failure: Build failed due to errors
[ERROR] [error]: Build step io.quarkus.resteasy.reactive.server.deployment.ResteasyReactiveProcessor#setupEndpoints threw an exception: java.lang.RuntimeException: java.lang.RuntimeException: Failed to process method 'companyx.api.extension.ExtensionClient#save'
[ERROR] at org.jboss.resteasy.reactive.common.processor.EndpointIndexer.createEndpoints(EndpointIndexer.java:315)
[ERROR] at io.quarkus.resteasy.reactive.server.deployment.ResteasyReactiveProcessor.setupEndpoints(ResteasyReactiveProcessor.java:613)
[ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
[ERROR] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:568)
[ERROR] at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:909)
[ERROR] at io.quarkus.builder.BuildContext.run(BuildContext.java:281)
[ERROR] at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
[ERROR] at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2449)
[ERROR] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1478)
[ERROR] at java.base/java.lang.Thread.run(Thread.java:833)
[ERROR] at org.jboss.threads.JBossThread.run(JBossThread.java:501)
[ERROR] Caused by: java.lang.RuntimeException: Failed to process method 'companyx.api.extension.ExtensionClient#save'
[ERROR] at org.jboss.resteasy.reactive.common.processor.EndpointIndexer.createResourceMethod(EndpointIndexer.java:754)
[ERROR] at org.jboss.resteasy.reactive.common.processor.EndpointIndexer.createEndpoints(EndpointIndexer.java:404)
[ERROR] at org.jboss.resteasy.reactive.common.processor.EndpointIndexer.createEndpoints(EndpointIndexer.java:286)
[ERROR] ... 12 more
[ERROR] Caused by: javax.enterprise.inject.spi.DeploymentException: No annotations found on fields at 'companyx.api.extension.Extension'. Annotations like `@QueryParam` should be used in fields, not in methods.
[ERROR] at org.jboss.resteasy.reactive.server.processor.ServerEndpointIndexer.handleBeanParam(ServerEndpointIndexer.java:185)
[ERROR] at org.jboss.resteasy.reactive.common.processor.EndpointIndexer.createResourceMethod(EndpointIndexer.java:612)
[ERROR] ... 14 more
[ERROR] -> [Help 1] So, I took that specific bean apart piece by piece until I could reproduce the error again...ithe error occurs when it hits this annotation @Schema(hidden = true)
@DefaultValue("CREATED")
private ExtensionStatus status = ExtensionStatus.CREATED; I believe the reason is that by using @DefaultValue we trigger the @BeanParam (per the javadocs of the annotation) even though it is not a BeanParam! That is why the error about "nothing being annotated for @BeanParam" gets thrown because it thought that payload was a BeanParam and there were not normal BeanParam (PathParam, QueryParam, etc.) annotated fields. This is also why we could not reproduce it (or if we did it was by mistake and not obvious). Never thought about having all the annotated fields in there... So, you fixed the ambiguous BeanParam. This issue was a mis-used annotation that is meant for BeanParams but was used in a bean that is not one. I think this will close this ticket out once your changes are merged in! Thanks for all your help. |
Ah, OK, so that explains the second issue that I could not reproduce. Good work hunting it down! I didn't expect |
…f subtyping Fixes quarkusio#29227 (cherry picked from commit 433a289)
Describe the bug
Upgrading from 2.13.4 (everything working/tests run) to 2.14 and have run into an issue it appears with the @BeanParams. This prevents us from upgrading other dependencies such as Stork and Helm as well as being able to take advantage of some nice enhancements in 2.14.
There looks to be two issues but they might be related.
[ERROR] Caused by: javax.enterprise.inject.spi.DeploymentException: No annotations found on fields at 'companyx.api.feature.Feature'. Annotations like
@QueryParam
should be used in fields, not in methods.Caused by: javax.enterprise.inject.AmbiguousResolutionException: Beans: [CLASS bean [class=companyx.api.project.ProjectParams, id=9fbe6c147b4e4613d0947934fb37c85f9738382b], CLASS bean [class=companyx.api.storage.AssetParams, id=200da7b2e76e0435661fa5435234030fd029f6f6], CLASS bean [class=companyx.api.artifact.ArtifactParams, id=ccde4a7e2f9460f415624c81466a3936ac3253d7], CLASS bean [class=companyx.api.query.RowParams, id=fef36db73899ee70ae3eed9ab9975fc01852e211]]
Expected behavior
2.13 worked. These are generally pretty simple classes used for @BeanParams in both RESTful endpoints and the REST client.
Actual behavior
Fails to build and register REST endpoints and give ambiguous errors on classes used as @BeanParam.
Running build only
[ERROR] Caused by: javax.enterprise.inject.spi.DeploymentException: No annotations found on fields at 'companyx.api.feature.Feature'. Annotations like
@QueryParam
should be used in fields, not in methods.Running with tests
Caused by: javax.enterprise.inject.AmbiguousResolutionException: Beans: [CLASS bean [class=companyx.api.project.ProjectParams, id=9fbe6c147b4e4613d0947934fb37c85f9738382b], CLASS bean [class=companyx.api.storage.AssetParams, id=200da7b2e76e0435661fa5435234030fd029f6f6], CLASS bean [class=companyx.api.artifact.ArtifactParams, id=ccde4a7e2f9460f415624c81466a3936ac3253d7], CLASS bean [class=companyx.api.query.RowParams, id=fef36db73899ee70ae3eed9ab9975fc01852e211]]
How to Reproduce?
For the life of me, I cannot seem to replicate this but I am trying.
Scenario 1 - Just build the codebase (multimodule project) without tests.
Scenario 2 - Run the tests.
Output of
uname -a
orver
No response
Output of
java -version
17.0.2
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.14.0.Final
Build tool (ie. output of
mvnw --version
orgradlew --version
)Maven 3.8.4
Additional information
Similar to:
The text was updated successfully, but these errors were encountered: