-
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
Refine how resource classes with same components are merged #25489
Conversation
ad348f1
to
23bf08e
Compare
Thanks for looking into this @Postremus! While working on this, please make sure that the JAX-RS TCK is passing with this change |
@geoand |
Nope, it's this one: https://github.com/quarkusio/resteasy-reactive-testsuite. |
@geoand |
This comment has been minimized.
This comment has been minimized.
Test failures do not look related. The kafka dev service container could not be started.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
@stuartwdouglas any objections?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, looking at #25462 (comment), it seems like this was an opt-in feature of RESTEasy Classic.
So we should probably do the same here.
I don't see how This flag was first mentioned, as far as I found, in the migration guide for 3.0-beta-5 to 3.0-beta-6:
I found these integration tests in resteasy:
The test consisist of:
In WiderMappingTest ( Also, as far as I can tell, the handling of the flag This flag only changes the order of how resources with different paths are merged, but has no influence in how resources with the same paths are matched. I therefore believe that this fix is still correct, and no config switch is needed. We merge resources with the same path (components) on class level. No change is done to the specific resource matching. |
I am btw. happy to introduce a config switch for this @geoand , I just don't want to do anything based on false assumptions on how the old stack worked. However, this change passes the tck, and the resource class merge is imo what users (i.e. me) expect to happen anyway. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks ok.
@Postremus thanks for this. Any chance you can do a small benchmark to see if this introduces any noticeable overhead? |
yep, will prepare a test project and do a simple benchmark (e.g. look at either profiler data or check how long dev mode restarts take comperativly) |
Thanks! We also want to make sure throughput for simple hello-world style rest calls is not affected |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Postremus could you have another look at this one so that we finalize it?
I added a small suggestion.
keyBuilder.append("|"); | ||
} | ||
|
||
this.key = keyBuilder.toString(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My guess is that it would be better if you could compute the hashCode here and cache it in a final field.
@Postremus friendly ping. |
@Postremus are you still interested in driving this home? It seems like a rather good improvement |
@geoand I rebased and applied some minor tweaks to reduce the cost of this new layer. I think you're more equipped than me to see if it introduces some significant overhead? |
I'll have a look |
This comment has been minimized.
This comment has been minimized.
Resources classes where merged by using all components as map key. This leads to situations where the only differing property of a component may be its name. The name is for a DEFAULT_REGEX however not enough to be considered a different path itself. The merge is now based on a custom (String) key, build on properties which should enforce uniqueness when needed: type, literal, and pattern.
This all comes from the observations I did in HV: - Objects.hash() can be costly as it creates an array - no real need to compare the classes given we know this object will only be used in a map that is consistent Also: - we don't need to cache the hashCode as String.hashCode() has a cache - better use equals() than compareTo()
Fixed the styling issue and applied one more small enhancement |
✔️ The latest workflow run for the pull request has completed successfully. It should be safe to merge provided you have a look at the other checks in the summary. |
Fixes #25462
Resources classes where merged by using all components as map key. This leads to situations where the only differing property of a component may be its name. The name is for a DEFAULT_REGEX however not enough to be considered a different path itself.
The merge is now based on a custom (String) key, build on properties which should enforce uniqueness when needed: type, literal, and pattern.