`quarkus.scheduler.use-composite-scheduler=true` + `camel-quarkus-quartz` causes startup failure

[And-yyy]

Describe the bug

Adding the dependency camel-quarkus-quartz to a Quarkus application that already uses quarkus-quartz causes a startup failure:

UnsatisfiedResolutionException: No bean found for required type
[interface io.quarkus.quartz.QuartzScheduler] and qualifiers [[]]

Prerequisite: The property quarkus.scheduler.use-composite-scheduler=true must be set. Without this setting, the combination works fine.

Root cause: When use-composite-scheduler=true is set, the QuartzSchedulerImpl bean is apparently not registered with the type io.quarkus.quartz.QuartzScheduler in the CDI container. However, CamelQuartzRecorder$QuartzAutowiredLifecycleStrategy attempts to resolve exactly this bean type at runtime via Arc.container().select(QuartzScheduler.class) — and fails with

ERROR [io.quarkus.runtime.Application] (Quarkus Main Thread) Failed to start application: java.lang.RuntimeException: Failed to start quarkus
        at io.quarkus.runner.ApplicationImpl.doStart(Unknown Source)
        at io.quarkus.runtime.Application.start(Application.java:116)
        at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:119)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:79)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:50)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:143)
        at io.quarkus.runner.GeneratedMain.main(Unknown Source)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at io.quarkus.runner.bootstrap.StartupActionImpl$1.run(StartupActionImpl.java:151)
        at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: jakarta.enterprise.inject.UnsatisfiedResolutionException: No bean found for required type [interface io.quarkus.quartz.QuartzScheduler] and qualifiers [[]]
        at org.apache.camel.quarkus.core.CamelBootstrapRecorder.start(CamelBootstrapRecorder.java:55)
        at io.quarkus.runner.recorded.CamelBootstrapProcessor$boot173480958.deploy_0(Unknown Source)
        at io.quarkus.runner.recorded.CamelBootstrapProcessor$boot173480958.deploy(Unknown Source)
        ... 11 more
Caused by: java.lang.RuntimeException: jakarta.enterprise.inject.UnsatisfiedResolutionException: No bean found for required type [interface io.quarkus.quartz.QuartzScheduler] and qualifiers [[]]
        at org.apache.camel.quarkus.main.CamelMainRuntime.start(CamelMainRuntime.java:65)
        at org.apache.camel.quarkus.core.CamelBootstrapRecorder.start(CamelBootstrapRecorder.java:53)
        ... 13 more
Caused by: jakarta.enterprise.inject.UnsatisfiedResolutionException: No bean found for required type [interface io.quarkus.quartz.QuartzScheduler] and qualifiers [[]]
        at io.quarkus.arc.impl.InstanceImpl.bean(InstanceImpl.java:288)
        at io.quarkus.arc.impl.InstanceImpl.getHandle(InstanceImpl.java:246)
        at org.apache.camel.quarkus.component.quartz.CamelQuartzRecorder$QuartzAutowiredLifecycleStrategy.onContextInitializing(CamelQuartzRecorder.java:93)
        at org.apache.camel.impl.engine.AbstractCamelContext.doInit(AbstractCamelContext.java:2559)
        at org.apache.camel.quarkus.core.FastCamelContext.doInit(FastCamelContext.java:195)
        at org.apache.camel.support.service.BaseService.init(BaseService.java:85)
        at org.apache.camel.impl.engine.AbstractCamelContext.init(AbstractCamelContext.java:2258)
        at org.apache.camel.support.service.BaseService.start(BaseService.java:115)
        at org.apache.camel.impl.engine.AbstractCamelContext.start(AbstractCamelContext.java:2277)
        at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:211)
        at org.apache.camel.quarkus.main.CamelMain.doStart(CamelMain.java:72)
        at org.apache.camel.support.service.BaseService.start(BaseService.java:123)
        at org.apache.camel.quarkus.main.CamelMain.startEngine(CamelMain.java:129)
        at org.apache.camel.quarkus.main.CamelMainRuntime.start(CamelMainRuntime.java:49)
        ... 14 more

The bug is not fixed in the latest version 3.31.3 either.

Expected behavior

The application starts without UnsatisfiedResolutionException and io.quarkus.quartz.QuartzScheduler is registered at CDI container.

How to Reproduce?

Execute the minimal test project quartz-bug-test.zip with ./mvnw quarkus:dev. At startup the Exception occourse.

Minimal reproduction:

• Dependencies: quarkus-quartz + camel-quarkus-quartz + camel-quarkus-core
• Property: quarkus.scheduler.use-composite-scheduler=true
• No additional code needed — simply starting the application triggers the error.

Output of uname -a or ver

Darwin test.local 25.2.0 Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:56 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T6041 arm64

Output of java -version

openjdk version "21.0.8" 2025-07-15 LTS OpenJDK Runtime Environment Temurin-21.0.8+9 (build 21.0.8+9-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.8+9 (build 21.0.8+9-LTS, mixed mode, sharing)

Quarkus version or git rev

3.27.2

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.12 (848fbb4bf2d427b72bdb2471c22fced7ebd9a7a1) Maven home: /Users/test/.m2/wrapper/dists/apache-maven-3.9.12/6068d197 Java version: 21.0.8, vendor: Eclipse Adoptium, runtime: /Users/test/.sdkman/candidates/java/21.0.8-tem Default locale: en_GB, platform encoding: UTF-8 OS name: "mac os x", version: "26.2", arch: "aarch64", family: "mac"

Additional information

No response

[quarkus-bot]

/cc @machi1990 (quartz), @manovotn (quartz,scheduler), @mkouba (quartz,scheduler)

[manovotn]

Hm, the CompositeScheduler doesn't implement QuartzScheduler, just io.quarkus.scheduler.Scheduler.
And IIRC, if the composite one is present, all other scheduler impls have their metadata changes (added qualifier?) to workaround ambiguous dependencies when operating on just Scheduler type.

I need to double check in the code to be sure.

Also, glancing at Camel Quarkus code, it seems like they could just use the Scheduler type instead of QuartzScheduler and go with that? The composite scheduler should then work just fine.

EDIT: My bad, the code looks explicitly for the impl type.
Instead, Camel Quarkus can do the dynamic lookup for @Any QuartzScheduler which should work just fine.

[mkouba]

This seems to be a problem of camel-quarkus-quartz. When quarkus.scheduler.use-composite-scheduler=true is used, the metadata of a bean that implements io.quarkus.quartz.QuartzScheduler is transformed to include the io.quarkus.scheduler.runtime.Constituent qualifier, so it no longer has the @Default qualifier.

A workaround would be to inject/lookup @Any io.quarkus.quartz.QuartzScheduler instead.

[And-yyy]

Until fixed could we re-expose it without Qualifier in producer method?
So that CamelQuartzRecorder can pick it up.

Do I need to open a bug in quarkus-camel or camel project?

import io.quarkus.quartz.QuartzScheduler;
import io.quarkus.scheduler.runtime.Constituent;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.enterprise.inject.Produces;

/**
 * Workaround for camel-quarkus-quartz bug:
 * When quarkus.scheduler.use-composite-scheduler=true, the QuartzSchedulerImpl
 * bean gets a @Constituent qualifier and loses @Default. This producer
 * re-exposes it with the @Default qualifier so CamelQuartzRecorder can find it.
 */
public class QuartzSchedulerProducer {

    @Produces
    @ApplicationScoped
    QuartzScheduler quartzScheduler(@Constituent final QuartzScheduler constituent) {
        return constituent;
    }
}

[mkouba]

Until fixed could we re-expose it without Qualifier in producer method?
So that CamelQuartzRecorder can pick it up.

Hm, I think that it would be safe only if you annotate the producer with @Typed(QuartzScheduler.class), i.e. the bean will not have io.quarkus.scheduler.Scheduler in its set of bean types.

Do I need to open a bug in quarkus-camel or camel project?

https://github.com/apache/camel-quarkus

[And-yyy]

Thanks for the guidance, with the following the application starts without errors now.
I will create a ticket at camel-quarkus and reference it here.

import io.quarkus.quartz.QuartzScheduler;
import io.quarkus.scheduler.runtime.Constituent;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.enterprise.inject.Produces;
import jakarta.enterprise.inject.Typed;
import io.quarkus.arc.Unremovable;

/**
 * Workaround for camel-quarkus-quartz bug:
 * When quarkus.scheduler.use-composite-scheduler=true, the QuartzSchedulerImpl
 * bean gets a @Constituent qualifier and loses @Default. This producer
 * re-exposes it with the @Default qualifier so CamelQuartzRecorder can find it.
 */
public class QuartzSchedulerProducer {

    @Produces
    @ApplicationScoped
    @Typed(QuartzScheduler.class)
    @Unremovable
    QuartzScheduler quartzScheduler(@Constituent final QuartzScheduler constituent) {
        return constituent;
    }
}

[mkouba]

Thanks for the guidance, with the following the application starts without errors now.

Keep in mind, that this will only work if quarkus.scheduler.use-composite-scheduler=true is set. If quarkus.scheduler.use-composite-scheduler=false was set the build would fail with ambiguous dependency.

[manovotn]

I have sent the PR to the Camel repo since I already verified that it fixes the reproducer here anyway.

@mkouba I was also thinking whether we should mention in the docs that with composite scheduler in place, all other impls get the @Constituent qualifier? I went looking into the doc we have and we don't seem to mention it anywhere. Was that left out on purpose?

[mkouba]

I have sent the PR to the Camel repo since I already verified that it fixes the reproducer here anyway.

@mkouba I was also thinking whether we should mention in the docs that with composite scheduler in place, all other impls get the @Constituent qualifier? I went looking into the doc we have and we don't seem to mention it anywhere. Was that left out on purpose?

That's a good point. It looks like injecting io.quarkus.quartz.QuartzScheduler is an undocumented feature, because @Inject org.quartz.Scheduler mentioned in quarkus-quartz docs should still work, and the same applies to @Inject io.quarkus.scheduler.Scheduler (the preferred API).

Was that left out on purpose?

Yes. The @Constituent qualifier is not even part of the public API, it's an implementation detail, so I'd rather not mention it in the docs.

[manovotn]

I have sent the PR to the Camel repo since I already verified that it fixes the reproducer here anyway.
@mkouba I was also thinking whether we should mention in the docs that with composite scheduler in place, all other impls get the @Constituent qualifier? I went looking into the doc we have and we don't seem to mention it anywhere. Was that left out on purpose?

That's a good point. It looks like injecting io.quarkus.quartz.QuartzScheduler is an undocumented feature, because @Inject org.quartz.Scheduler mentioned in quarkus-quartz docs should still work, and the same applies to @Inject io.quarkus.scheduler.Scheduler (the preferred API).

Was that left out on purpose?

Yes. The @Constituent qualifier is not even part of the public API, it's an implementation detail, so I'd rather not mention it in the docs.

From your comment I am not sure whether you feel like we should add some docs or not :)

Seeing as it works, I think it might be better to leave it as it is because most users will stick to @Inject io.quarkus.scheduler.Scheduler anyway.
If we're agreed on that, I think we can close this issue as the PR on Camel side was merged.