I've started looking at the migration path at $work for Jakarta EE and while Tomcat 10 has some fantastic features to help with that (hot migration is killer IMO), there are still some potential barriers I'm seeing to "slowly" migrating $work applications from Java EE -> Jakarta EE.

When I say "slowly", I mean "not having to write one or more large revision-control changes to lock-step-upgrade from e.g. Tomcat 8/9 to Tomcat 10.1."

One specific example is that we use Apache Velocity as our page-generation language and AIUI, these templates will not have their text scanned and replaced with updated strings. For example:


This code looks to see if the request has the "javax.serlet.error.request_uri" attribute set and then takes some appropriate action.

In order to use this on Tomcat 10.1, we would need to replace that with the appropriate string. In order to make it work on *either* Tomcat 8/9 or 10, we'd need to change the code to:

#if($request.getAttribute('jakarta.servlet.error.request_uri') || $request.getAttribute('javax.servlet.error.request_uri'))

... and then we'd have semi-useless code laying around after the upgrade which would need to be cleaned-up afterward. Doable, but not super ideal.

This is the first such example I came across when looking at doing an upgrade in a development environment at $work, and I'm sure I will come up with some others.

I can think of a few ways to facilitate a dual-deployment (Tomcat 8/9 vs 10 aka Java EE vs Jakarta EE) application, at least for the specific example I present above:

1. Change everything all at once, force-upgrade to Tomcat 10.1 all at once. I find this infeasible, so I'm going to ignore it as an option for now.

2. Write dual-checking code (as shown above) where we simply have either 2 different code-paths for different environments, or double-up on our checking and usage of various Java/Jakarta request attributes. Yuck.

3. Write a Filter which copies from javax.servlet.* -> jakarta.servlet.* (or vice versa). This would allow us to immediately use the application under either environment.

4. Patch the server to provide #3 without having to include a Filter in the application deployment.

I'm kind of interested in idea #4, and wanted to ask for feedback.

I can't be the only one in this situation where the Tomcat Migration Tool is great but doesn't cover some use-cases and therefore upgrades are risky and/or problematic.

I think we as a community should be encouraging users to start upgrading to get over the "Jakarta Hurdle" and I think that this could be another small tool to help motivate that migration.



To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to