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?
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 them:
NettyServerBuilder.maxConcurrentCallsPerConnection(...)call.java.time: a newTime.getIsoTimeStringhelper for the six log-formatting call sites.Why are these changes required?
To pick up upstream fixes, remove obsolete compatibility code, and reduce unused or legacy dependencies. Specifically:
TODO: Remove this shim after grpc/grpc-java#12930 is fixed. That fix shipped in v1.83.1, which now enforces the advertised concurrent-stream limit at handler startup — exactly what the shim did.commons-lang33.4 was the declared version only: libp2p already forces 3.18.0 onto the runtime classpath, so this aligns the declaration with what actually ships.commons-mathhas no imports anywhere; Joda-Time was used only for log formatting and test date arithmetic, both expressible with the JDK.This PR has been tested by:
Compatibility notes
--log-configfiles continue to load and emit logs.jmxConfiguratoris ignored by Logback 1.3, so JMX-based logging management is no longer available.DefaultShutdownHook.SizeAndTimeBasedRollingPolicychecksmaxFileSizeless frequently, so log files may temporarily exceed the configured limit during heavy writes.org.slf4j.impl.StaticLoggerBinder. Reflections 0.9.11 probes for that class to decide whether to log, so its own scan diagnostics are now silent. All of its logging sites are null-guarded, so there is no functional impact; actuator registration still fails loudly throughTronError(ACTUATOR_REGISTER).Extra details
UTC timestamp output remains unchanged. Non-UTC output may use updated offsets from the JDK time-zone database while still representing the same instant.