Package io.github.pimak.ntfy.quarkus.runtime

Class NtfyRecorder

java.lang.Object
io.github.pimak.ntfy.quarkus.runtime.NtfyRecorder
public class NtfyRecorder extends Object
Records the creation of the ntfy log Handler at RUNTIME_INIT. The deployment processor invokes create() from a @Record(RUNTIME_INIT) build step and feeds the result to a LogHandlerBuildItem. The handler itself is the framework-neutral NtfyJulHandler from ntfy-jul; this recorder only binds it to Quarkus config and lifecycle.

Native-image safety hinges on this being RUNTIME_INIT: the engine builds its HttpClient, worker threads, and digest scheduler inside AlertEngine.start(), which NtfyJulHandler.forConfig(io.github.pimak.ntfy.core.NtfyConfig) invokes here at application boot — never at build time or static-init.

  • Constructor Details

    • NtfyRecorder

      public NtfyRecorder(io.quarkus.runtime.RuntimeValue<NtfyRuntimeConfig> config)
      The run-time config is injected through the recorder constructor. Since Quarkus 3.19+ a RUN_TIME @ConfigRoot can no longer be consumed directly as a @BuildStep parameter; it must be received here wrapped in a RuntimeValue.

  • Method Details

    • create

      public io.quarkus.runtime.RuntimeValue<Optional<Handler>> create()
      Builds the ntfy JUL handler from the run-time config. Returns Optional.empty() when the config is inactive (disabled, or missing the url/topic endpoint), so Quarkus installs no handler at all.

      Either way the handler's pipeline counters are published to NtfyPipelineCountersHolder — the live instance when a handler was installed, null otherwise. That is the only handle the Micrometer binding gets on the handler Quarkus now owns, and clearing it on the inactive path keeps a dev-mode reload from leaving the meters pointed at the previous application's counters.