Re: Apache Tomcat 10 Issue

Christopher Schultz <[email protected]> Tue, 3 Mar 2026 08:25:42 -0500
Newsgroups gmane.comp.jakarta.tomcat.user
Message-ID <[email protected]>
David,

On 3/2/26 2:35 PM, David Wall wrote:
>> as others already pointed out, Tomcat 9.0.16 is over 6 years old. See 
>> https://tomcat.apache.org/tomcat-9.0-doc/changelog.html
>> Tomcat 9.0.115 has been released about 1 month ago, so you should be 
>> good here for now. Tomcat 9 will be under active development (i.e. 
>> security fixes!) until roughly one year from now. Shortly before that 
>> you can think about moving to another major Tomcat version, if this 
>> app of yours is still in use. 
> 
> How long do you think Tomcat 10 will support the 'webapps-javaee' 
> location for auto-migration of javax.servlet to jakarta.servlet?

I don't see a reason we would drop support for this for a good long 
time. There isn't much of a reason to drop it, given how small of a 
component it actually is. It basically goes the equivalent of "sed -e 
's/javax\.//jakarta\./g'" on all your files. It's *somewhat* more 
complicated than that, but it doesn't require a great deal of maintenance.

> While we have migrated our own source code to use jakarta.servlet,
> we have hooks to old open source libraries like Vaadin 8 that are
> built on javax with deep ties to GWT and Atmosphere and others that
> make upgrading fully to jakarta.servlet nearly impossible. We
> currently depend on Tomcat 10's 'webapps-javaee' to migrate for us
> and it seems we do have a working 'webapps' code base as we know
> that Tomcat 9 will go away eventually and we need to prepare as best
> we can now.  I presume if webapps-javaee were to no longer be
> supported in Tomcat 10, we could run the migration tool directly,
> but it is convenient for us to release our code into webapps-javaee,
> let Tomcat auto-migrate it, and then release to others from the
> resulting webapps.
I'd recommend that you DO use the Migration Tool to run your legacy JAR 
files through it a single time, then use those moving forward instead of 
the originals. It will make your deployments faster, and you don't have 
to have a deploy-before-release strategy.

-chris