All,
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:
#if($request.getAttribute('javax.servlet.error.request_uri'))
...
#end
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.
WDYT?
Thanks,
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
