On Mon, Nov 10, 2025 at 4:12 PM Mark Thomas <[email protected]> wrote:
> On 10/11/2025 20:14, Coty Sutherland wrote: > > Hi all, > > > > I'm looking at extending the version.sh output > > And version.bat ? > Oops, yes. > > > to print the version of apr, > > openssl (including when used via FFM), and tcnative that are available on > > the system (so usable, but not necessarily configured for use in the > > server.xml). > > So it will pull in the configuration from setenv.sh (like it does now) > and then report the libraries it could load if configured in server.xml > given the current environment? So if there are multiple versions if > Tomcat Native, it will list them both? > Yeah, that's the idea. So far I'm only looking at changing the ServerInfo class and adding a few system properties to the scripts. > > I like it. > Excellent :D > > > I also think it could be useful to list the name and version > > information from third party jars in lib/. > > OK. Initially, I wasn't sure about ecj.jar but given we tell folks they > can replace it with a newer version then listing it does make sense. > > > Basically I want to pull all of > > the library version information from the log for the libraries loaded and > > have it returned here so that version.sh gives a full picture of the > > environment and not just the tomcat, JDK, and OS output. > > > > Obviously this requires extending o.a.c.util.ServerInfo, which is a bit > > more involved than I thought it might be :) I would need to add the > > classpath and catalina home and base to the catalina.sh script's > execution > > of the version block so that ServerInfo has access to those. > > Makes sense. > > > I think I can > > access all the things I want with reflection to init the classes > > Is there any refactoring we can do to reduce the amount of reflection > required? I'm thinking of AprLifecycleListener, JniLifecycleListener etc. > I hadn't looked at that yet, but I'll see if I can make some suggestions to expose the version info in the listeners and use that instead of reflection. > > > and get > > version info, and use java.util.jar.* to check the jars in lib/. Before > I> dive too much into implementation I wanted to ask if anyone has thoughts > > about this proposal or if there are suggestions for other useful things > we > > could add. If there's no objections, I'll add submitting a PR to my TODO. > > Maybe the include the values of: > CATALINA_BASE > CATALINA_HOME > java.library.path > I hadn't done that because the output of version.sh has several "Using..." lines at the top which including CATALINA_HOME, etc i.e. ``` Using CATALINA_BASE: /tomcat/output/build Using CATALINA_HOME: /tomcat/output/build Using CATALINA_TMPDIR: /tomcat/output/build/temp Using JRE_HOME: /usr/lib/jvm/java-latest-openjdk Using CLASSPATH: /tomcat/output/build/bin/bootstrap.jar:/tomcat/output/build/bin/tomcat-juli.jar Using CATALINA_OPTS: ``` I can add them easily though if you think we should restructure that output so it's not duplicated? > > > > > Here's some example output: > > > > ``` > > Server version: Apache Tomcat/12.0.0-M1-dev > > Server built: Oct 22 2025 17:47:46 UTC > > Server number: 12.0.0.0 > > OS Name: Linux > > OS Version: 6.17.4-200.fc42.x86_64 > > Architecture: amd64 > > JVM Version: 25+36 > > JVM Vendor: Red Hat, Inc. > > APR loaded: true > > APR Version: 1.7.6 > > Tomcat Native: 1.3.0 > > WARNING: Tomcat recommends a minimum version of 2.0.5 > > OpenSSL (APR): OpenSSL 3.2.6 30 Sep 2025 > > OpenSSL (FFM): OpenSSL 3.2.6 > > > > Third-party libraries: > > ecj-4.37.jar: 3.43.0.v20250819-1513 > > random.jar: (unknown) > > jakartaee-migration-1.0.9-shaded.jar: 1.0.9 > > ``` > > Looks good. > Cool, thanks. I'll see about getting a PR for this soon(er than the test one probably as it's a bit more interesting). Thanks for the feedback! > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
