All,
On 10/12/26 6:05 PM, Christopher Schultz wrote:
All,
On 10/12/26 12:43 PM, Christopher Schultz wrote:
All,
Tomcat ships with a package-renamed version of the Apache commons-
pool2 and commons-dbcp2 projects, minus a few classes that we don't
need (I think).
I don't see a reason for the Tomcat team to maintain a separate copy
of the source tree, manage patches from upstream, etc.
My proposal is to drop the source from our repository and instead
maintain the desired version number and hashes as we do for other
dependencies (e.g. commons-daemon), and automatically shade the
commons- * release JARs as part of the Tomcat release process.
I'm sure I'll be able to get download and shading working, but I may
need some help with the OSGi stuff. My plan would be to use Jar Jar
Links[1] (yes, that's the name of the project) for the actual shading:
it already has an ant task which extends <jar> which means it should
support our reproducible-build timestamps. It should be able to handle
merging pool2 and dbcp2 together and re-writing the dependencies
correctly.
NOTE: While this will require a network connection to download these
artifacts during the build, it does not represent an *additional*
network connection: we already require a network connection if other
artifacts are not present locally. Performing a "download-compile"
should be sufficient to gather the required dependencies before
disconnecting from a network. The release can then be built without a
working network connection.
-chris
[1] https://github.com/shevek/jarjar
Okay, jarjar is old and uses its own (old) version of ASM which means it
(silently!) does not work with newer Java class file versions. :(
There are still other options, of course. It might even be possible to
add an ad-hoc profile to the Migration Tool which can do this for us.
Progress.
As a proof-of-concept, I:
1. Created a minimal Maven project
2. ... which has commons-pool2 2.13.1 as a (direct) dependency
3. ... and also has commons-dbcp2 2.14.0 as a (direct) dependency
4. Combines and shades the two above libraries into a single JAR
5. ... and also re-writes references from org.apache.logging ->
org.apache.juli
This produces a JAR file that worked for my JDBC-based application
deployed and running on Tomcat 9.0.122. I simply replaced the existing
tomcat-dbcp.jar file with the one produced by the Maven project
described above.
Some remaining potential issues:
1. The META-INF/MANIFEST.MF file in the resulting library does not match
what Tomcat's release build currently produces.
2. How to actually achieve the above process for a release build?
3. commons-dbcp2 is implementing the Java EE API for javax.transaction
which won't work properly on Tomcat 10.1.x and later.
Potential answers for the above 3 items:
1a. I'm not sure how much that matters, as Tomcat is not meaningfully
using Java modules, here.
2a. Proposal: new subproject:tomcat-dbcp (not to be confused with
tomcat-pool, which is in module/!)
3a. Proposals:
i. subproject:tomcat-dbcp has a packaging option for *also* re-naming
javax.transaction -> jakarta.transaction
ii. Tomcat 9 does nothing, Tomcat 10.1.x + add an additional
release-build step which is to run jakartaee-migration tool
on tomcat-dbcp.jar prior to release.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
