Quartz Scheduler Extension: Startup `log4j:WARN` and dependency audit for Lucee 7.1+

hacking extensions
1

Context & Summary
With Lucee 7 retiring the legacy internal scheduler in favor of the Quartz Scheduler Extension (id: E99E43A5-C10E-41E9-878BFC82BAAD99CE), Quartz is now a core component of the runtime.

Starting in Lucee 7.1, any server or container boot running the Quartz extension emits the following warning to stderr during startup:

log4j:WARN No appenders could be found for logger (org.quartz.impl.StdSchedulerFactory).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
SLF4J(W): No SLF4J providers were found.
SLF4J(W): Defaulting to no-operation (NOP) logger implementation
SLF4J(W): See https://www.slf4j.org/codes.html#noProviders for further details.

We checked the upstream repository across all branches (including master at 1.1.0.14-SNAPSHOT and 1.0 at 1.0.0.69-SNAPSHOT). The root cause is the dependency declarations in JavaSettings.cfc, Quartz.cfc, and maven-dependencies.xml.

Root Cause of the Warning

Quartz.cfc and JavaSettings.cfc declare the following Maven dependencies:

{
  "groupId": "log4j", "artifactId": "log4j", "version": "1.2.17"
},
{
  "groupId": "org.slf4j", "artifactId": "slf4j-log4j12", "version": "1.7.7"
}
  1. Quartz does not use Log4j: Quartz 2.3.2 is built natively against slf4j-api.
  2. Missing Appender: Bundling slf4j-log4j12 routes SLF4J calls directly into Log4j 1.x. Because no log4j.properties is provided on the classpath when StdSchedulerFactory initializes, Log4j 1.x warns about missing appenders.
  3. Security / End of Life: log4j:1.2.17 reached End-of-Life in 2015 and carries known high-severity vulnerabilities (CVE-2019-17571, CVE-2022-23302, etc.). Lucee core modernized to Log4j 2 long ago; bundling legacy Log4j 1.x in the core scheduler extension is unnecessary risk.

Additional Dependency Audit

Looking at the remaining entries in javaSettings.maven, several other libraries appear to be copy-pasted artifacts from Quartz’s standalone distribution that Lucee never actually uses:

  1. com.zaxxer:HikariCP-java7:2.4.13 (Obsolete):

    • This is an ancient Java 7 backport from 2015. Lucee 7 runs on Java 11/17/21+.
    • When configured with a Lucee datasource (store.type = "datasource"), Quartz uses Lucee’s own ConnectionProviderImpl.cfc, which borrows connections directly from Lucee’s datasource manager (pc.getDataSourceManager()). HikariCP-java7 is never invoked.

  2. com.mchange:c3p0:0.9.5.4 (Redundant for Lucee stores):

    • Like HikariCP, c3p0 is only used by standalone Quartz setups managing their own JDBC pools. When Lucee datasources are used, ConnectionProviderImpl handles pooling.

  3. org.quartz-scheduler:quartz-jobs:2.3.2 (Unused):

    • quartz-jobs only contains built-in utility jobs (DirectoryScanJob, FileScanJob, SendMailJob, NativeJob).
    • Lucee executes tasks through its own custom CFML wrappers (ComponentJob.cfc and URLJob.cfc), so quartz-jobs is unused overhead.

  4. org.slf4j:slf4j-api:1.7.7 (Redundant & pins ancient version):

    • org.quartz-scheduler:quartz:2.3.2 already pulls slf4j-api transitively.
    • Explicitly pinning 1.7.7 (from 2014) in javaSettings.maven risks classloader collisions if application code or other Lucee 7 extensions load modern SLF4J 2.x libraries.

Verification

We verified running org.quartz-scheduler:quartz:2.3.2 with only slf4j-api on modern JVMs (Java 17/21/25). Quartz initializes, starts the thread pool, schedules/fires tasks, and shuts down cleanly with zero Log4j warnings.

Proposed Recommendations

  1. Remove Log4j 1.x:
    Drop log4j:log4j:1.2.17 and org.slf4j:slf4j-log4j12:1.7.7. Route Quartz’s SLF4J calls through Lucee core’s logging infrastructure (e.g. log4j-to-slf4j or Log4j 2 provider).
  2. Prune Unused Libraries:
    Remove com.zaxxer:HikariCP-java7, com.mchange:c3p0, and org.quartz-scheduler:quartz-jobs.
  3. Let Quartz resolve its own SLF4J:
    Drop the hardcoded org.slf4j:slf4j-api:1.7.7 entry so it resolves transitively from quartz:2.3.2 without pinning an ancient 2014 version.

Cleaning this up will eliminate the startup warning, trim ~6 MB of unused jars from every container/server download, and align the extension with Lucee 7’s modern Java baseline.

2

Thanks @philsw for digging into this and for the thorough audit, that makes it easy to act on. You’re right that shipping log4j 1.2.17 in the scheduler extension isn’t something we want. I’ve filed it as Jira with PRs for master and 1.0: they drop log4j 1.x and slf4j-log4j12 (which removes the startup warnings), stop pinning slf4j-api 1.7.7, and remove our explicit HikariCP-java7, c3p0 and quartz-jobs declarations. One caveat: quartz 2.3.2’s own pom still pulls c3p0 and HikariCP in transitively, so fully dropping those needs exclusion support on our side. I’ll report back here once there’s a snapshot to test.

3

Thanks @GianTschingt for the quick turnaround!

Tested 1.0.0.69-SNAPSHOT in our build and container startup—the log4j:WARN message is completely gone and everything initialized cleanly.

Appreciate you getting LDEV-6662 sorted so quickly!

4

Thanks @philsw for testing 1.0.0.69-SNAPSHOT and confirming the warning is gone, and for taking the time to help improve Lucee. I’ve closed LDEV-6662 as deployed.