chore(deps): upgrade grpc, jackson, logback, commons and drop joda-time - #6950
Open
halibobo1205 wants to merge 5 commits into
Open
chore(deps): upgrade grpc, jackson, logback, commons and drop joda-time#6950halibobo1205 wants to merge 5 commits into
halibobo1205 wants to merge 5 commits into
Conversation
1. bump grpcVersion to 1.83.1 to pick up the upstream fix for grpc/grpc-java#12930 (PR grpc/grpc-java#12942), which enforces connection.remote().maxActiveStreams(maxStreams) at handler startup 2. drop GrpcNettyMaxConcurrentStreamsLimiter, the local protocol-negotiator shim that applied the same limit while 1.83.0 left the remote endpoint unbounded until the client acknowledged SETTINGS
bump jackson-databind from 2.18.6 to 2.18.10 to pick up cumulative fixes from the 2.18.x line
1. bump logback-classic from 1.2.13 to 1.3.16 and slf4j-api, jcl-over-slf4j, jul-to-slf4j from 1.7.36 to 2.0.17; logback 1.3 requires the slf4j 2.0 provider model, and 1.3.16 is the last 1.3.x release and the ceiling for the x86_64 JDK 8 build, since 1.5.x requires JDK 11 2. rename DelayingShutdownHook to DefaultShutdownHook in the toolkit logback.xml; logback 1.3 removed the old class and only auto-maps the legacy name with a startup warning 3. drop the CONSOLE appender from the toolkit logback.xml; no logger ever referenced it, so it never emitted output on 1.2 either, and logback 1.3 now flags it with an unreferenced-appender warning 4. accept one known 1.3.x behavior change: SizeAndTimeBasedRollingPolicy now throttles its maxFileSize comparison to once per 60s (SimpleInvocationGate) instead of the adaptive ~100-800ms gate of 1.2.13, so under sustained heavy logging a file can overshoot the 500MB cap by up to 60s of writes before the %i rollover fires; time-based rollover and totalSizeCap/maxHistory cleanup are ungated and unaffected 5. note for operators running a custom --log-config file: well-formed 1.2-era configs using standard elements keep working unchanged (jmxConfigurator degrades to an ignored-property warning, the legacy shutdown hook name is auto-mapped), and malformed XML still fails fast via TronError(LOG_LOAD) exactly as on 1.2; however, a config that references an uninstantiable class (e.g. a custom appender missing from the classpath) now aborts the whole appender-ref phase instead of losing just that one appender, so the node starts with no log output while the ERROR statuses are printed to stdout by LogService
1. bump commons-lang3 from 3.4 to 3.20.0; the runtime classpath already resolved 3.18.0 through libp2p 2.2.9's transitive requirement, so align the declaration with what actually ships and move past the CVE-2025-48924 range that the nominal 3.4 still sits in 2. bump commons-collections4 from 4.1 to 4.6.0 3. remove commons-math 2.2; no source file imports org.apache.commons.math and nothing else in the dependency graph requests it
1. drop the joda-time 2.3 dependency. 2. replace the six new DateTime(millis) log-formatting call sites in DynamicPropertiesStore, DposTask and DposService with a new Time.getIsoTimeString helper backed by java.time; its formatter (yyyy-MM-dd'T'HH:mm:ss.SSSXXX in the system zone) reproduces joda's DateTime.toString() output byte for byte where the JDK and joda 2.3 time-zone databases agree (UTC nodes are unaffected); zones whose rules changed after joda's 2013-era tzdb, e.g. Europe/Moscow, now render the corrected offset for the same instant. 3. replace DateTime.now() day arithmetic in four test classes with the java.time equivalent, ZonedDateTime.now().minusDays(n)/plusDays(n) .toInstant().toEpochMilli(), keeping joda's calendar semantics one-to-one, and map plain DateTime.now().getMillis() to System.currentTimeMillis()
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Upgrade dependencies and remove obsolete dependencies and compatibility code:
io.grpc:grpc-*com.fasterxml.jackson.core:jackson-databindch.qos.logback:logback-classicorg.slf4j:slf4j-api/jcl-over-slf4j/jul-to-slf4jorg.apache.commons:commons-lang3org.apache.commons:commons-collections4org.apache.commons:commons-mathjoda-time:joda-timeAlong with these changes:
NettyServerBuilder.maxConcurrentCallsPerConnection(...)call.java.time, introducingTime.getIsoTimeStringfor log formatting and migrating date arithmetic in tests.ToolkitLogback configuration.Why are these changes required?
gRPC 1.83.1 enforces the concurrent-stream limit at handler startup, before the client acknowledges SETTINGS. This covers the behavior previously supplied by the local shim. See the gRPC 1.83.1 release notes.
Logback 1.3.16 preserves the x86_64 build's JDK 8 requirement while incorporating fixes absent from 1.2.13, including the CVE-2025-11226 backport and removal of
JaninoEventEvaluator. Logback 1.3 uses the SLF4J 2.0 provider model, so SLF4J is upgraded alongside it. See Logback's maintenance status and runtime requirements, the 1.3.16 release notes, and the 1.3.15 security backports.commons-mathhas no direct source references, and the existing Joda-Time usages can be replaced with JDK APIs.This PR has been tested by:
Compatibility notes and migration requirements
The bundled default logging configurations have been verified. Users supplying a custom
--log-configshould review the following changes and migrate affected configurations before upgrading.Include paths that depend only on XML-defined properties require migration.
In the example below, when
includediris defined only in the XML and no system property, environment variable, or fallback value supplies it, Logback 1.3.16 fails to resolve the include path:Under these conditions, the path resolves to
includedir_IS_UNDEFINED/appenders.xml, relative to the process working directory. Logback 1.2.13 resolves the same configuration correctly. In 1.3.16,doConfigurereturns without throwing, so this failure does not raiseTronError(LOG_LOAD). If the failed include supplies all of the application's logging destinations, application logs are discarded. Independently configured destinations can remain operational.The failure is reported to the console:
LogServicecallsStatusPrinter.printInCaseOfErrorsOrWarnings, which printsWARN in ch.qos.logback.core.joran.action.IncludeAction - Failed to open [.../includedir_IS_UNDEFINED/appenders.xml]to the console at startup.Verified workarounds are to use a literal absolute include path, or to supply the property through a JVM argument such as
-Dincludedir=/etc/tron/logging. Upstream documented a fix in 1.5.5; the 1.3.16 artifact used here still exhibits this behavior. See the Logback 1.5.5 release notes.Janino-based expression evaluators must be migrated.
The removal of
JaninoEventEvaluatorwas backported in Logback 1.3.15 to address CVE-2024-12798, so it applies to this upgrade to 1.3.16. See the Logback 1.3.15 release notes. AnEvaluatorFilterusing the implicit evaluator syntax<evaluator><expression>…</expression></evaluator>behaves differently depending on whether Janino is present on the classpath:NoClassDefFoundError: org/codehaus/janino/ScriptEvaluatoron 1.2.13. ThisErrorbypassesLogService'scatch (Exception)and aborts startup. On 1.3.16, configuration processing instead returns normally with the filter inactive. The project does not declare Janino as a dependency.EventEvaluatorimplementation.The bundled default configuration does not use this feature. See the evaluator migration instructions.
JMX-based logging management is no longer available.
The entire
ch.qos.logback.classic.jmxpackage was removed in 1.3.x, so<jmxConfigurator/>is now reported as an unknown property and ignored, where 1.2.13 loaded it silently.The legacy shutdown hook name still works, with a warning.
DelayingShutdownHookwas renamed toDefaultShutdownHook. Logback 1.3.16 still accepts the old name through a compatibility mapping and warns before instantiating the new class, so existing operator configurations keep working. This PR does not rely on that mapping: the bundled Toolkit configuration has been migrated toDefaultShutdownHook.Log files may exceed the configured size threshold.
SizeAndTimeBasedRollingPolicychecks file size less frequently. Under sustained heavy logging, individual files may temporarily exceedmaxFileSize. Time-based rollover andmaxHistory/totalSizeCapcleanup are unaffected.Invalid appender classes may affect other logging destinations.
A custom configuration referencing a missing or uninstantiable appender class produces console errors and may also prevent other appender references from being attached.
Reflections scan diagnostics are no longer emitted.
SLF4J 2.x removes
org.slf4j.impl.StaticLoggerBinder, which Reflections 0.9.11 probes to determine whether logging is available. Its own diagnostic logging is therefore disabled. Scanning remains functional, all of its logging sites are null-guarded, and actuator registration failures still surface throughTronError(ACTUATOR_REGISTER).Timestamp formatting
Ordinary UTC timestamp output has been verified against the previous implementation. Non-UTC output may use different offsets because the JDK and the older Joda-Time release contain different time-zone databases, while still representing the same instant.