quarkusio/quarkus · error · DeploymentException

Mixing Quarkus REST and RESTEasy Classic client parts is not

Error message

Mixing Quarkus REST and RESTEasy Classic client parts is not supported

What it means

Quarkus detected a Quarkus REST (reactive) client dependency (`quarkus-rest-client` capability) together with a RESTEasy Classic stack, which cannot coexist in one deployment. The two HTTP client stacks are incompatible, so deployment fails with a DeploymentException.

Source

Thrown at extensions/resteasy-reactive/rest-common/deployment/src/main/java/io/quarkus/resteasy/reactive/common/deployment/ResteasyReactiveCommonProcessor.java:113

    void checkMixingStacks(Capabilities capabilities, CurateOutcomeBuildItem curateOutcomeBuildItem,
            List<IgnoreStackMixingBuildItem> ignoreStackMixingItems) {
        if (!ignoreStackMixingItems.isEmpty()) {
            return;
        }
        List<ResolvedDependency> resteasyClassicDeps = curateOutcomeBuildItem.getApplicationModel().getDependencies().stream()
                .filter(d -> d.getGroupId().equals("org.jboss.resteasy")).toList();
        boolean hasResteasyCoreDep = resteasyClassicDeps.stream()
                .anyMatch(IS_NOT_TEST_SCOPED.and(IS_RESTEASY_CLASSIC_CORE_DEP));
        if (!hasResteasyCoreDep) {
            return;
        }
        boolean hasResteasyClassicClient = resteasyClassicDeps.stream()
                .anyMatch(IS_NOT_TEST_SCOPED.and(IS_RESTEASY_CLASSIC_CLIENT_DEP));
        if (!hasResteasyClassicClient) { // there is no bulletproof way of knowing whether a server specific dependency has been included, so we deduce it by the absence of client dependency
            throw new DeploymentException("Mixing Quarkus REST and RESTEasy Classic server parts is not supported");
        }
        if (capabilities.isPresent(Capability.REST_CLIENT_REACTIVE)) {
            throw new DeploymentException(
                    "Mixing Quarkus REST and RESTEasy Classic client parts is not supported");
        } else {
            LOG.warn(
                    "Mixing Quarkus REST server and RESTEasy Classic client parts might lead to unexpected results. Consider using 'quarkus-rest-client' instead of 'quarkus-resteasy-client'.");
        }
    }

    @BuildStep
    void searchForProviders(Capabilities capabilities,
            BuildProducer<AdditionalApplicationArchiveMarkerBuildItem> producer) {
        if (capabilities.isPresent(Capability.RESTEASY) || capabilities.isPresent(Capability.RESTEASY_CLIENT)
                || QuarkusClassLoader.isClassPresentAtRuntime(
                        "org.jboss.resteasy.plugins.providers.JaxrsServerFormUrlEncodedProvider")) { // RESTEasy Classic could be imported via non-Quarkus dependencies
            // in this weird case we don't want the providers to be registered automatically as this would lead to multiple bean definitions
            return;
        }
        producer.produce(new AdditionalApplicationArchiveMarkerBuildItem(PROVIDERS_SERVICE_FILE));
        producer.produce(new AdditionalApplicationArchiveMarkerBuildItem(

View on GitHub (pinned to e1c734241f)

Solutions

1. Replace the Classic client `quarkus-resteasy-client` usage with `quarkus-rest-client` (reactive) — remove the classic client/server deps
2. Or go fully Classic: use `quarkus-resteasy` + `quarkus-resteasy-client` and remove all reactive rest extensions
3. Inspect `mvn dependency:tree` to find and exclude the dependency introducing the conflicting client capability

Example fix

// before
<dependency>io.quarkus:quarkus-resteasy</dependency>
<dependency>io.quarkus:quarkus-rest-client</dependency>
// after
<dependency>io.quarkus:quarkus-rest-client</dependency>
<dependency>io.quarkus:quarkus-rest</dependency>

// CI check before build:
// mvn dependency:tree -Dincludes=io.quarkus:quarkus-rest-client,io.quarkus:quarkus-resteasy-client
grep -q 'quarkus-rest-client' pom.xml && grep -q 'quarkus-resteasy<' pom.xml && echo 'MIXED STACK ERROR' && exit 1 || true

When it happens

Trigger: Having `quarkus-resteasy` (classic) plus `quarkus-rest-client` (reactive client) in the same application — e.g. mixed quickstart code or a transitive reactive-client dependency.

Common situations: Following old docs using `quarkus-resteasy` with new reactive client starters; partial stack migration; a dependency transitively requiring the reactive client.

Related errors

• Mixing Quarkus REST and RESTEasy Classic server parts is not
• The OpenID Connect Database Token State Manager extension is
• Multiple HealthCheckResponseProvider implementations found:
• A generic type is not allowed here; try creating a subclass
• Build item class must be leaf (final) types: %s

AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/428db1097b422c2b. Report an issue: GitHub.