quarkusio/quarkus · error · DeploymentException

Mixing Quarkus REST and RESTEasy Classic server parts is not

Error message

Mixing Quarkus REST and RESTEasy Classic server parts is not supported

What it means

Quarkus detects that a deployment contains both Quarkus REST (RESTEasy Reactive) server dependencies and RESTEasy Classic server dependencies without the Classic client marker, which is an unsupported mixed stack. The classic-client dependency is used as a heuristic: its absence implies a classic server part was pulled in. Deployment aborts with a DeploymentException.

Source

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

    @Produce(ServiceStartBuildItem.class)
    @BuildStep
    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;

View on GitHub (pinned to e1c734241f)

Solutions

Remove the RESTEasy Classic server dependency (`quarkus-resteasy`) and migrate endpoints to Quarkus REST (`quarkus-rest`)
If Classic is intentional, it must be the whole stack — remove the reactive server extensions
Check `mvn dependency:tree` for who pulls in `quarkus-resteasy` transitively and exclude it

Example fix

// before (pom.xml)
<dependency>io.quarkus:quarkus-rest</dependency>
<dependency>io.quarkus:quarkus-resteasy</dependency>
// after
<dependency>io.quarkus:quarkus-rest</dependency>

Defensive patterns

Strategy: validation

Validate before calling

// run before build:
// mvn dependency:tree -Dincludes=io.quarkus:quarkus-resteasy
grep -q 'quarkus-resteasy<' pom.xml && ! grep -q 'quarkus-rest<' pom.xml || echo 'conflict risk'

Prevention

Never mix quarkus-rest and quarkus-resteasy in one app
Run mvn dependency:tree in CI to detect transitive classic deps
Standardize team on Quarkus REST (reactive) stack

When it happens

Trigger: Adding `quarkus-resteasy` (classic) alongside `quarkus-rest`/`quarkus-resteasy-reactive` to the same application, e.g. accidentally via a transitive dependency or starter, with no `quarkus-resteasy-client` dependency.

Common situations: Adding an older library/quickstart module that still uses RESTEasy Classic; migration halfway between stacks; an extension transitively bringing in classic server deps.

Related errors

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