Adobe ColdFusion (2025 release) now uses Tomcat 10.1, upgrading from Tomcat 9, and supports servlet specifications 6.0, replacing 4.0.
Why?
- Availability of new features – Tomcat 10 introduces many new features, while Tomcat 9 primarily focuses on security updates and vulnerability fixes.
- Improved performance
- Enhanced security
- Compatibility with newer Java applications
- Support for newer specifications
- Servlet specification upgrade.
- Tomcat 9 – Servlet 4.0 API specifications
- Tomcat 10.1 – Servlet 6.0 API specifications
- Servlet specification upgrade.
What has changed?
This namespace change is part of the transition from Java EE, managed by Oracle, to Jakarta EE under the Eclipse Foundation.
Some functions that had been deprecated for a long time have now been removed. For example,
- Response.setStatus – this method is removed due to ambiguous meaning of the message parameter.
- Request.getRealPath – use ServletContext.getRealPath().
- Connector configuration in server.xml is not relaxed anymore. The following configuration needs to be updated. The key credentials need to be provided in standard configuration format.
-
Not working example - <Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="8443" scheme="https" secure="true" SSLEnabled="true"keystoreFile="yourCertificateHere" keystorePass="certPass" clientAuth="false" sslProtocol="TLS"/>
-
Working config example - <Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="8443" maxThreads="150" SSLEnabled="true" scheme="https" secure="true"> <SSLHostConfig> <Certificate certificateKeystoreFile="yourCertificateHere" certificateKeystorePassword="certPass" type="RSA" /></SSLHostConfig> </Connector>
-
Jars changed (packaging changed) – The Java package used by the specification APIs has changed from javax. to jakarta. It will be necessary to recompile web applications against the new APIs.
Impact on ColdFusion 2025
- Updated reference from javax.servlet to jakarta.servlet package.
- Update methods which were deprecated and removed.
- Some jars are available with Jakarta specifications. Where upgrade was possible, was done.
- Some are not available. For this, eclipse has provided with transformation utility, which would transform existing jars to Jakarta specifications.
Note: That last step and the next section do not apply to CF applications: they are required only if there is a jar/war included by CF developers which refers to older servlet specification.
How to update your JAR/WAR/EAR codebase, if required?
Migration is a tedious process, and Eclipse has provided a tool for the rescue.
Eclipse Foundation has provided a utility, called Eclipse Transformer – It can be used to transform final application binary (JAR, WAR and EAR). It modifies the Java bytecode and updates the resources to refer to the current correct packages (e.g. javax.servlet to jakarata.servlet). For WAR and EAR files, it automatically transforms nested JARs.
Eclipse Transformer can be found here on github
Download eclipse transformer jar file
Input file name – jakarta-ee-8-app.war
Output file name – jakarta-ee-10-app-transformed.war
java -jar transformer/org.eclipse.transformer.cli-0.5.0.jar jakarta-ee-8-app.war jakarta-ee-10-app-transformed.war
The transformed file is ready.
To update your codebase, you will have to make following changes –
- Update import packages from javax.servlet to Jakarta.servlet
- Check if you are using tomcat jar functions which are not present anymore – Find the list here Deprecated List (Apache Tomcat 10.0.27 API Documentation)
- Use new jars which are either
- available in their repository or
- Transform the existing jars
Resources
- Apache 10.1 – Apache Tomcat 10 (10.1.33) – Documentation Index
- Tomcat 10 deprecated and removed features/functions – Deprecated List (Apache Tomcat 10.0.27 API Documentation)
- Transform your application to Jakarta – Eclipse Transformer | projects.eclipse.org
- GitHub for eclipse transformer – GitHub – eclipse/transformer: Eclipse Transformer provides tools and runtime components that transform Java binaries, such as individual class files and complete JARs and WARs, mapping changes to Java packages, type names, and related resource names.
Thanks for this update on changes in cf to support tomcat 10.1. That said, we should clarify for readers that after point 3 in the “impact ” list, all the rest (about Eclipse and the Transformer) is NOT something for cf developers to be concerned with. It’s for those deploying their own WAR files on Tomcat.
You must be logged in to post a comment.