-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Make Hibernate Reactive tests use @RunOnVertxContext and upgrade the Context validity checks #23905
Conversation
Because you are creating a root context and not a duplicated context :-) |
I need the magic sauce to get to that duplicated context 😉 |
Nevermind, found it, so let me try |
Success! |
@Sanne all this PR needs now if the Hibernate tests to be ported (which is what the last commit started). Do you want to do that? |
Many thanks! Nice, there are some similarities with what I was toying with yesterday: In particular I was preparing to introduce an attribute for the |
How important is the module rename commit cf06953? If possible I'd refrain from that, so to not introduce breaking changes. |
...ernate-reactive/deployment/src/test/java/io/quarkus/hibernate/reactive/SchemaUpdateTest.java
Show resolved
Hide resolved
@@ -28,12 +27,15 @@ | |||
@Inject | |||
Mutiny.SessionFactory sessionFactory; | |||
|
|||
@RunOnVertxContext |
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.
That's not enough, what kind of context is it running on?
Event loop context, worker context, duplicated context?
The default should be a duplicated context, but we may need parameters to create the right type of context.
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.
Right - like I suggested I believe we should have some attributes on the annotation to make things explicit and controllable.
But I think "duplicated" could be a reasonable default.
But I'm ok fixing that as a follow up myself, if there's agreement on the direction :)
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.
Since you folks know more about what needs to be done, I'm fine with letting you add more metadata to the annotation :)
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.
Cool, yes thanks a lot to implement the testing tool bits. I was trying yesterday but honestly got lost - not familiar with it at all so I appreciate you doing that part.
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.
Yeah, it's too easy to get lost with all the necessary classloader hacks...
@@ -74,7 +75,7 @@ public Object invoke(Object actualTestInstance, Method actualTestMethod, List<Ob | |||
CompletableFuture<Object> cf = new CompletableFuture<>(); | |||
RunTestMethodOnContextHandler handler = new RunTestMethodOnContextHandler(actualTestInstance, actualTestMethod, | |||
actualTestMethodArgs, uniAsserter, cf); | |||
vertx.getOrCreateContext().runOnContext(handler); | |||
VertxContext.getOrCreateDuplicatedContext(vertx).runOnContext(handler); |
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 we need to give more flexibility. Yes, the default should be a duplicated context with its root being the event loop context, but we may need some other cases.
That being said, that should always run on a duplicated context.
Not really possible to avoid unfortunately because of the dependency of the existing module on |
Yeah, I think it makes sense. Feel free to make any changes you like in the PR :) |
I think this is done now - could @geoand and/or @cescoffier have another look? |
LGTM |
@Sanne does that mean that anyone using HR will have to annotate their tests? |
It should only affect users of the "internal" testing extension
|
Ok, cool, good to know. |
Force pushed another fix |
@geoand for who is it actually a breaking change? To be clear Hibernate Reactive always had the requirement to run on a vert.x context - it just so happens it was able to bypass this requirement in these specific integration tests because the use the internal testing tools which aren't meant for end users. The only user-affecting change I see is that
Let me know if you think I'm forgetting some aspect :) |
It breaks anyone using
But as we both said, this is very unlikely to have been used by anybody as we never mentioned it anywhere. So to summarize, it's breaking, but it's rather unlikely to affect anyone. |
@geoand ah, sure. But you clarified that in the description already - I thought you meant there was more breaking stuff on top of it. I think we're good in that case - perhaps I wouldn't have changed the module names as I said earlier, but you said you had no choice :) If we're doing what we can IMO we'll need to go ahead and ask for forgiveness. |
Agreed |
That may not be 100% true, as it has broken the super heroes sample app. It doesn't break people just using the See #23612 (comment) Just my opinion here (and I'm late to this as I am just returning from PTO - so what's done is done), but introducing breaking changes like this shouldn't be done in minor versions. I also understand that I don't fully understand the context which required the breaking change, so circumstances certainly could have warranted it, but it should be avoided in minor versions unless absolutely necessary. |
* Bump quarkus.platform.version from 2.7.2.Final to 2.7.3.Final Bumps `quarkus.platform.version` from 2.7.2.Final to 2.7.3.Final. Updates `quarkus-bom` from 2.7.2.Final to 2.7.3.Final - [Release notes](https://github.com/quarkusio/quarkus-platform/releases) - [Commits](quarkusio/quarkus-platform@2.7.2.Final...2.7.3.Final) Updates `quarkus-maven-plugin` from 2.7.2.Final to 2.7.3.Final --- updated-dependencies: - dependency-name: io.quarkus.platform:quarkus-bom dependency-type: direct:production update-type: version-update:semver-patch - dependency-name: io.quarkus.platform:quarkus-maven-plugin dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> * Fix based on quarkusio/quarkus#23905 Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Eric Deandrea <eric.deandrea@gmail.com>
hi @edeandrea , could you point me to the test in the super heroes app that was affected? It would help me to see a concrete example, as think this only affects either internal testing API or code which wasn't running in the right context to begin with. I might be wrong though :) |
@Sanne https://github.com/quarkusio/quarkus-super-heroes/blob/main/rest-heroes/src/test/java/io/quarkus/sample/superheroes/hero/repository/HeroRepositoryTests.java (after I made changes). I had to change the Here's the commit: quarkusio/quarkus-super-heroes@5050d31 |
so, the problem is the artifactId change. @geoand do you believe we can to a relocation? |
Its not just the artifactId change - also the package relocation from |
Yeah, I didn't do the relocation thing because the package also had to change. |
I guess I don't fully follow why the package had to change? Could we have a deprecated copy of the annotation in the previous location? |
|
The old package didn't make sense after the repurposing of the API to work for both internal and user facing tests |
Ok but that's not a reason that it had to change ? I would suggest introducing a deprecated alternative for both the removed types. |
There were too many changes that stacked up which is why I didn't see the reason for trying to keep compatibility |
[edited by @Sanne ]
This makes the internal integration tests of Hibernate Reactive use the
@RunOnVertxContext
annotation and also:@RunOnVertxContext
also work for internal testsquarkus-junit5-vertx
- necessary to resolve cross-module dependenciesThis resolves all remaining concerns I had in regards to context usage for H.R.
N.B. This is a breaking change because the module name of
quarkus-junit5-vertx
was changed toquarkus-test-vertx
(as it now needs to supportquarkus-junit5-internal
), the dependency onquarkus-junit5
was removed and the API changed packages (fromio.quarkus.test.junit.vertx
toio.quarkus.test.vertx
).