On 1/13/26 06:59, Christopher Schultz wrote:
Mark and Rob,
Thank you Chris and Mark,
One more question, below. Or five. And maybe a feature request.
On 1/13/26 3:52 AM, Mark Thomas wrote:
On 12/01/2026 19:12, Rob Sargent wrote:
Hello again, it's been a minute
I may need to upgrade my embedded tomcat application and have a
couple of questions.
Other than the obvious javax.<servlety-stuff> -> jakarta
substitutions what else does it change?
Exactly which Java EE -> Jakarta EE conversion it does depend on
which profile you pick. Options are:
- just Servlet
- all the APIs Tomcat provides
- all the Java EE specs
There is also a Jakarta EE to Java EE profile if you need to down
convert.
Other things converted:
- OSGi dependencies in MANIFEST.MF files.
Can the tool "update in-place"?
You can use it in three ways.
1. Standalone. Pass it a WAR/JAR/directory and it will convert it.
2. On deployment. Place your WAR file in webapps-javaee and Tomcat
will create a converted version in webapps and load it.
3. At runtime by setting the jakartaConverter attribute of the Loader
to the required conversion profile name.
I have run the tool on my "webapp" source dir, which has only a half
a dozen servlets. Should I also run the tool in the app source dir
which also has some javax.servlet etc imports? Indeed, run it over
my entire code base?
It needs to run over all your source code. For each dependency you
either need to obtain a Jakarta EE compatible JAR or use the tool to
convert a Java EE JAR. Note some dependencies will not use Java EE
APIs and won't need updating / converting.
I do want to be perfectly clear: you can run the tool *on your source
code*; it's not just a WAR/JAR converter.
So run it on your source and check the changes with your revision
control system to see what it did.
I successfully ran to tool directly against my source code, with none of
the options added to the command line. Wonderful. My first guess was to
supply just the <source> dir but then set <destination> same as
<source>. Bingo. Perhaps a little unexpected but it works.
But now of course I have jakarta and javax (naming, sql, xml) imports.
Is it wiser (and part of the tool's capabilities) to replace those as
well? Maybe a little future-proofing? Wouldn't this then make one less
dependency? jakarta-11?
Then switch any dependencies you know about for their Jakarta
equivalents. Then build and test, swapping-out anything that isn't
working for its Jakarta equivalent.
For those packages which aren't available targeted at the Jakarta
APIs, run those JAR files through the converter either as a part of
your build or pre-build with stored-local JAR files.
-chris
Not sure if there's any attempt to address any of the build
environments, but if so adding gradle's build.gradle files to the mix
would be greatly appreciated.
Thanks again to you all,
rjs
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
