Repository navigation
Conversation
|
Please fix conflicts. Also: we're expecting you're reviewing, testing, and editing before opening the PR. Including a statement of "never ran CI tests" doesn't make me super confident. You can run them locally with |
That's why I announced this in Discord first. I let the agents do their thing and I'm also reviewing these now and running tests. I supposed I could've marked them Drafts. |
NicoPiel
changed the title
|
@NicoPiel You can't have any merge commits in your PR with the project's linear history requirement. If you hard reset your branch to the myBatis commit before the merge (7f8f597), you can do an interactive rebase and drop the dbcp2 commit. After that you can do a clean rebase on main with only 3 commits in the PR. I wouldn't worry about the removals missing from |
2.5.1 is from 2016. 7.1.0 is the current release and runs on Java 11+; it needs only slf4j-api at runtime, which the build already ships (the metrics and javassist dependencies are optional and unused here). The calls in HikariConnectionPool are unchanged in 7.x: a connectionTimeout of 0 still means wait indefinitely, and ProxyConnection.unwrap(Connection.class) still returns the driver's connection. Behavior that does change comes from upstream defaults, such as idle connections now being pinged every two minutes (keepaliveTime) and SQLTimeoutException no longer evicting a connection. Signed-off-by: Nico Piel <nico.piel@hotmail.de>
2.3 is from 2015, and commons-dbcp2 releases from 2.10 on need a recent pool2. 2.x has stayed source and binary compatible for the pool calls in KeyEncryptor and FileConnector, which still compile against 2.13.1; the millisecond setters FileConnector uses are deprecated in favor of Duration ones but behave the same. commons-parent 34 was only the parent of pool2 2.3, so its checksum entry is dropped too. Signed-off-by: Nico Piel <nico.piel@hotmail.de>
3.1.1 is from 2012. 3.5.19 is the last Java 8 release of the 3.5 line. 3.6.0 is only days old, so this stays on 3.5. OGNL and javassist are still shaded inside the mybatis jar, and nothing else is needed at runtime. The 3.5 line binds a simple parameterType's type handler from the declared type. User.selectPreferencesForUser declared java.lang.String but is called with the Integer user id, so it now declares java.lang.Integer in every database's mapper. Upstream Mirth made the same change when it moved to 3.5.15. The other String and Integer parameterTypes match what their callers pass. mybatis-parent 15 was only the parent of 3.1.1, so its checksum entry is dropped too. Signed-off-by: Nico Piel <nico.piel@hotmail.de>
439d496 to
83622e2
Compare
|
Done, thanks |
What
Bumps three stale database-layer libraries, one commit each:
This PR originally also bumped commons-dbcp2. Main has since removed the custom DBCP pooling and the dbcp2 dependency, so that commit was dropped and the branch rebased onto main.
Why
MyBatis 3.1.1 dates from 2012, and the pools are equally old.
Reviewer notes
parameterType.User.selectPreferencesForUserdeclaredjava.lang.Stringbut receives an Integer, so it's nowjava.lang.Integerin all 5 database mappers. This is the same fix upstream Mirth made.SqlMapConfig.xmlwas loaded under 3.5.19 with the 24 real argument cases bound. All pass. The#{name}bind parameters from main's event-search SQL injection fix also work under 3.5.connectionTimeout(0)still means wait forever.SQLTimeoutExceptionno longer evicts the connection.build dist), and parent POMs that only the old versions used were pruned. The dbcp2 2.14.0 entry stays because the OWASP dependency-check plugin still resolves it. THIRD-PARTY-README now also lists the Javassist copy bundled inside MyBatis.Testing
verifyVendoredParity, 137 unit tests, and a staged server on a fresh Derby DB driven through about 30 REST calls (users and preferences, channels, deploy, messages, search, statistics, events).GET /events/countwithout a level filter returns 500, with MyBatis 3.1.1 too.🤖 Generated with Claude Code