-
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
Re-enable MutinyTest #11828
Re-enable MutinyTest #11828
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -21,7 +21,6 @@ | |
import javax.ws.rs.sse.SseEventSource; | ||
|
||
import org.junit.jupiter.api.Assertions; | ||
import org.junit.jupiter.api.Disabled; | ||
import org.junit.jupiter.api.Test; | ||
|
||
import com.fasterxml.jackson.databind.ObjectMapper; | ||
|
@@ -43,7 +42,6 @@ | |
|
||
@QuarkusTest | ||
@QuarkusTestResource(MongoTestResource.class) | ||
@Disabled("See https://github.com/quarkusio/quarkus/issues/11711") | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There's also There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, missed that, thought it was just the one. I'm loathed to re-trigger the full CI build, can it be in a followup if this is ok? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Same here.
I think that's OK since if this re-enabled regular test passes, it's almost guaranteed the native one too will, given the context of this issue. So we just need to see how this one goes. |
||
class ReactiveMongodbPanacheResourceTest { | ||
private static final TypeRef<List<BookDTO>> LIST_OF_BOOK_TYPE_REF = new TypeRef<List<BookDTO>>() { | ||
}; | ||
|
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.
Does the execution order play a role here? @jaikiran reported that sometimes the server one was initialized first and sometimes the client one.
I think we should have a build item ensuring that the order of operations is fully determined.
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.
To my understanding, the only time there's a problem is when the server one is created first and the REST Client one clobbers it.
I don't think the reverse situation poses any problems.
In addition, there are many times where only the server or only REST Client is present, so I'm not sure how a BuildItem helps in that situation
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.
Another point to note is that the provider factory for server or client side are actually different instances of the same class, where the "server" instance has a no-op for all client operations, and the "client" instance the reverse.
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.
We could have a build item in one of the artifacts common to the two, the server would produce it and the client optionally consume it.
This way, if the server is present, we would be sure the client code would be executed after the server code.
Obviously, we can also do the opposite if it makes more sense.
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.
Another option, which will take some time, is to add the functionality we have for
RestClientBuilderImpl
toResteasyClientBuilderImpl
that can use a static method to set the provider directly into the instance.Then ordering isn't an issue.
I've raised https://issues.redhat.com/browse/RESTEASY-2684 to discuss this option with the RESTEasy team
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.
Again, I want to be sure we properly control the execution order.
@kenfinnigan I can do the work and push an additional commit to your PR if you don't think it's useful.
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 don't see it as necessary or useful
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.
To reiterate, with this change it's not necessary to control the execution order. And I'm looking to properly fix it in RESTEasy so this wouldn't be needed long term either.
I don't see the need to further complicate the code for a change that isn't permanent
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 but that won't be for 1.8 and we need a fix now.
And I really think having a deterministic execution order for things that interact with each other is important.
If just for the sake of not spending hours debugging weird issues.
I think adding the build item should be very easy. I'll take a look tomorrow. Either it's easy and don't add boilerplate or I will give up.
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 know it won't be done for 1.8, but why add more code that needs to be removed when it's there in 1.9?
When the change is done in RESTEasy, there is no longer a need for a build item