Summary
The bundled Jetty 9.4.58.v20250814 distribution's upstream/etc/jetty.xml emits one WARN line per startup:
WARN [org.eclipse.jetty.xml.XmlConfiguration] Ignored arg
<Arg name="threadpool"><Ref refid="threadPool"/></Arg>
in file:///.../upstream/etc/jetty.xml
This is upstream Jetty behavior (the line is in the file the Jetty distribution itself ships), not something our security or hardening work added. The followup PR will silence it by removing the offending <Arg> from the vendored copy in system/Tools/jetty/upstream/etc/jetty.xml.
Why this is benign (and why the line is being ignored)
org.eclipse.jetty.server.Server in 9.4.58 has only one constructor with a ThreadPool parameter:
public Server(org.eclipse.jetty.util.thread.ThreadPool);
with parameter name pool (not threadpool). The compiled bytecode doesn't carry the MethodParameters attribute (verified with javap -p -v), so Jetty's XmlConfiguration can't match the name="threadpool" attribute to the constructor parameter. The arg is logged as ignored, the Server() no-arg constructor is used instead, and a default QueuedThreadPool is created.
Side finding (separate, NOT in scope for this fix)
Because the line is ignored, the threadpool Jetty module's threadPool bean (with minThreads=10, maxThreads=200, idleTimeout=60000, etc., defined in upstream/modules/threadpool.mod → etc/jetty-threadpool.xml) is not actually used by the Server. The Server is silently using a default QueuedThreadPool (minThreads=8, maxThreads=200). The only behavioral difference is 2 min threads. Documenting here so the followup is tracked; not changing behavior in this fix to keep it a pure warning-suppression.
If we ever want the threadpool module's config to actually take effect, the right XML change is to drop the name attribute (<Arg><Ref refid="threadPool"/></Arg>) so XmlConfiguration matches by position. That's a behavior change and should be a separate, deliberate PR.
Plan
- Add a vendored
system/Tools/jetty/upstream/etc/jetty.xml (full file, with the offending <Arg name="threadpool"> line removed). The antrun copy task in modules/perc-jetty/pom.xml (phase process-resources, last sub-task) overlays system/Tools/jetty/ onto ${assembly-directory} after the upstream Jetty distribution is unpacked, so the vendored file wins.
- Add a short comment above the removed line explaining why it's gone, so a future Jetty upgrade reader doesn't re-add it.
- Branch:
bugfix/<this-issue>-suppress-jetty-threadpool-ignored-arg; commit, GPG-sign, push, open PR.
Verification
After rebuild of modules/perc-jetty and redeploy, jetty/base/logs/server.log no longer contains the Ignored arg <Arg name="threadpool"> line. The startup log is otherwise unchanged.
Co-Authored by Mavis Mavis-Code using MiniMax-M3 with agent mavis.
Summary
The bundled Jetty 9.4.58.v20250814 distribution's
upstream/etc/jetty.xmlemits one WARN line per startup:This is upstream Jetty behavior (the line is in the file the Jetty distribution itself ships), not something our security or hardening work added. The followup PR will silence it by removing the offending
<Arg>from the vendored copy insystem/Tools/jetty/upstream/etc/jetty.xml.Why this is benign (and why the line is being ignored)
org.eclipse.jetty.server.Serverin 9.4.58 has only one constructor with aThreadPoolparameter:with parameter name
pool(notthreadpool). The compiled bytecode doesn't carry theMethodParametersattribute (verified withjavap -p -v), so Jetty'sXmlConfigurationcan't match thename="threadpool"attribute to the constructor parameter. The arg is logged as ignored, theServer()no-arg constructor is used instead, and a defaultQueuedThreadPoolis created.Side finding (separate, NOT in scope for this fix)
Because the line is ignored, the
threadpoolJetty module'sthreadPoolbean (with minThreads=10, maxThreads=200, idleTimeout=60000, etc., defined inupstream/modules/threadpool.mod→etc/jetty-threadpool.xml) is not actually used by the Server. The Server is silently using a defaultQueuedThreadPool(minThreads=8, maxThreads=200). The only behavioral difference is 2 min threads. Documenting here so the followup is tracked; not changing behavior in this fix to keep it a pure warning-suppression.If we ever want the
threadpoolmodule's config to actually take effect, the right XML change is to drop thenameattribute (<Arg><Ref refid="threadPool"/></Arg>) soXmlConfigurationmatches by position. That's a behavior change and should be a separate, deliberate PR.Plan
system/Tools/jetty/upstream/etc/jetty.xml(full file, with the offending<Arg name="threadpool">line removed). The antruncopytask inmodules/perc-jetty/pom.xml(phaseprocess-resources, last sub-task) overlayssystem/Tools/jetty/onto${assembly-directory}after the upstream Jetty distribution is unpacked, so the vendored file wins.bugfix/<this-issue>-suppress-jetty-threadpool-ignored-arg; commit, GPG-sign, push, open PR.Verification
After rebuild of
modules/perc-jettyand redeploy,jetty/base/logs/server.logno longer contains theIgnored arg <Arg name="threadpool">line. The startup log is otherwise unchanged.