Class NtfyJulHandler
Handler that forwards SEVERE-and-above (and, when a warn route is configured,
WARNING) LogRecords to the ntfy AlertEngine. This is the framework-neutral JUL adapter: attach it to any
java.util.logging logger (plain JUL apps, Tomcat, Helidon, …), or let a framework install it —
the Quarkus extension feeds it to a LogHandlerBuildItem, so it sees every log record the
application produces (JUL, JBoss LogManager, and the SLF4J/Log4j bridges all funnel through
java.util.logging).
For zero-code installation see NtfyJulAutoHandler (declarative,
logging.properties) and NtfyJulInstaller (programmatic one-liner).
A logging handler must never throw, or it can corrupt the caller's logging path; every publish(java.util.logging.LogRecord) is fully guarded. Level gating mirrors the other adapters: records at Level.SEVERE (JUL's ERROR-equivalent) or above are always alerted, and Level.WARNING
records only once the engine activated a warn route (warn-topic). Nothing below WARNING
is ever alerted.
-
Constructor Summary
ConstructorsConstructorDescriptionNtfyJulHandler(AlertEngine engine) Equivalent toNtfyJulHandler(AlertEngine, List)with an empty MDC allow-list, i.e. no MDC values in the alert body.NtfyJulHandler(AlertEngine engine, List<String> includeMdcKeys) -
Method Summary
Modifier and TypeMethodDescriptionvoidclose()counters()The alert pipeline's observability counters for this handler's engine — the JUL counterpart of the Logback/Log4j2 appenders'getCounters().voidflush()static NtfyJulHandlerforConfig(NtfyConfig config) Builds a handler around a fresh, startedAlertEngineforconfig, with engine self-diagnostics routed toSystem.err(never back through the logging pipeline — seeJulDiagnostics).voidMethods inherited from class java.util.logging.Handler
getEncoding, getErrorManager, getFilter, getFormatter, getLevel, isLoggable, reportError, setEncoding, setErrorManager, setFilter, setFormatter, setLevel
-
Constructor Details
-
NtfyJulHandler
Equivalent toNtfyJulHandler(AlertEngine, List)with an empty MDC allow-list, i.e. no MDC values in the alert body. Retained as an explicit constructor so callers written against an earlier release stay both source- AND binary-compatible: the(AlertEngine)descriptor keeps linking without recompilation, and its behavior is unchanged. -
NtfyJulHandler
- Parameters:
engine- an already-startedengine; this handler owns its lifecycle and stops it onclose().includeMdcKeys- the MDC keys whose values may be rendered into the alert body, in rendering order — an explicit allow-list with no wildcard form;nullor empty means no MDC value is ever read. Defensively copied, so a later mutation of the caller's list cannot widen what this handler publishes.
-
-
Method Details
-
forConfig
Builds a handler around a fresh, startedAlertEngineforconfig, with engine self-diagnostics routed toSystem.err(never back through the logging pipeline — seeJulDiagnostics). The single construction path shared by the programmatic installer, the auto-handler, and the Quarkus extension's recorder.configshould beactive; an inactive or invalid config never throws — the engine refuses activation with a diagnostic and the returned handler simply drops records.Because this is the single construction path, forwarding
NtfyConfig.getIncludeMdcKeys()here is the ONE change that wiresinclude-mdc-keysthrough every installation route at once:NtfyJulInstaller,NtfyJulAutoHandlerand the Quarkus extension's recorder all build their handler throughforConfig, so none of them needs to know the option exists. -
counters
The alert pipeline's observability counters for this handler's engine — the JUL counterpart of the Logback/Log4j2 appenders'getCounters(). Read-only and pulled, never logged, so surfacing them (in a Micrometer meter, a health check, a JMX bean, …) cannot re-enter the logging pipeline.Unlike the appenders, a handler owns exactly one engine for its whole lifetime — it is constructed around an already-started engine and stops it on
close()— so the returned instance is stable and its tallies are monotonic for as long as the handler is installed. Re-installing the handler (a newforConfig) yields a new engine with fresh counters. -
publish
-
flush
public void flush() -
close
public void close()
-