-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Allow running Wiremock without HTTP Server #1572
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
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
691b2eb
to
0902d82
Compare
Hey, please could you rebase this against master? |
0902d82
to
aed48e5
Compare
Thanks Tom, have done 👍 |
aed48e5
to
9dad745
Compare
As noted in wiremock#1476, a common search online is to run Wiremock without needing an HTTP server, for instance if using a serverless deployment model. It is currently possible to do this using the `WireMockApp`, which relies on internal APIs, which will break when we move to Java Modules. To avoid this, we can implement the `DirectCallHttpServer` as a first class citizen, which, when created, will allow consumers to retrieve the mapped `Response` (whatever it may be) for Stub and Admin requests. We can use the existing Jetty `stopTimeout` configuration to control the configuration for this server's async timeouts, so consumers can override it in cases they need delays on responses. Because we're using the `HttpResponder`s as callbacks, we need to use Mockito's `doAnswer` to invoke the real `HttpResponder` from our mock. We also add the Mockito Jupiter bindings to more easily write JUnit Jupiter tests using Mockito. Finally, we want to add an example test to show consumers how they can use it for themselves. Closes wiremock#1476.
9dad745
to
05ab471
Compare
timtebeek
reviewed
Oct 19, 2021
class Stop { | ||
@Test | ||
void doesNothing() { | ||
assertDoesNotThrow(() -> server.start()); |
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.
Suggested change
assertDoesNotThrow(() -> server.start()); | |
assertDoesNotThrow(() -> server.stop()); |
jamietanna
added a commit
to jamietanna/wiremock
that referenced
this pull request
Oct 21, 2021
As a follow-up to wiremock#1572.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As noted in #1476, a common search online is to run Wiremock without
needing an HTTP server, for instance if using a serverless deployment
model.
It is currently possible to do this using the
WireMockApp
, whichrelies on internal APIs, which will break when we move to Java Modules.
To avoid this, we can implement the
DirectCallHttpServer
as a firstclass citizen, which, when created, will allow consumers to retrieve the
mapped
Response
(whatever it may be) for Stub and Admin requests.We can use the existing Jetty
stopTimeout
configuration to control theconfiguration for this server's async timeouts, so consumers can
override it in cases they need delays on responses.
Because we're using the
HttpResponder
s as callbacks, we need to useMockito's
doAnswer
to invoke the realHttpResponder
from our mock.We also add the Mockito Jupiter bindings to more easily write JUnit
Jupiter tests using Mockito.
Finally, we want to add an example test to show consumers how they can
use it for themselves.
Closes #1476.
Depends on #1565, but otherwise ready for reviews