WireMock only uses log4j in its test dependencies. Neither the thin nor standalone JAR depends on or embeds log4j, so you can continue to use WireMock 2.32.0 and above without any risk of exposure to the recently discovered vulnerability.
- HTTP response stubbing, matchable on URL, header and body content patterns
- Request verification
- Runs in unit tests, as a standalone process or as a WAR app
- Configurable via a fluent Java API, JSON files and JSON over HTTP
- Record/playback of stubs
- Fault injection
- Per-request conditional proxying
- Browser proxying for request inspection and replacement
- Stateful behaviour simulation
- Configurable response delays
Full documentation can be found at wiremock.org
If you have a question about WireMock, or are experiencing a problem you're not sure is a bug please post a message to the WireMock mailing list.
On the other hand if you're pretty certain you've found a bug please open an issue.
We welcome bug fixes and new features in the form of pull requests. If you'd like to contribute, please be mindful of the following guidelines:
- All changes should include suitable tests, whether to demonstrate the bug or exercise and document the new feature.
- Please make one change per pull request.
- If the new feature is significantly large/complex/breaks existing behaviour, please first post a summary of your idea on the mailing list to generate a discussion. This will avoid significant amounts of coding time spent on changes that ultimately get rejected.
- Try to avoid reformats of files that change the indentation, tabs to spaces etc., as this makes reviewing diffs much more difficult.
- Abide by the Architecture Rules enforced by ArchUnit.
To run all of WireMock's tests:
./gradlew clean testTo build both JARs (thin and standalone):
./gradlew jar shadowJar The built JAR will be placed under build/libs.
To publish both JARs to your local Maven repository:
./gradlew publishToMavenLocal