Le 2021-02-09 22:12, Mark Thomas a écrit :
Thoughts?
I think this feature is really desirable. For the Debian packaging this
would mean a faster transition to Tomcat 10.
There are two issues:
1. How to identify a legacy application?
2. How to convert the application once identified?
For the identification, either:
a. separate the Java EE and Jakarta EE webapps in different directories.
It's simple but it's an additional decision point for the user and there
will be mistakes.
b. keep the webapps in the same directory and scan the content. This
degrades the performances for those having switched to Jakarta EE, so
this should be optional, and probably disabled by default.
c. keep the webapps in the same directory, load them as usual and
trigger the conversion mechanism only if a class loading error related
to the javax namespace occurs.
Regarding the conversion, we can:
a. Convert at runtime with class loading tricks, which is quite elegant
but the price is paid every time the application is started.
b. Convert at deployment time before loading the application, this means
more file juggling but only the first start is impacted.
The convenience of the automatic migration comes obviously at a price
but I think it's important we ensure it doesn't impact those ready to
jump to the new Jakarta EE world. For this reason I'm leaning toward the
solution 1c + 2b (convert on errors, and convert the webapp before
reloading).
The start sequence would look like this:
1. foo.war is copied to the webapps directory by the user
2. The foo application is loaded
3. A NoClassDefFoundError regarding the javax.servlet.Servlet class is
thrown, the migration mechanism is triggered
4. The migration tool is executed on foo.war. The original file is
renamed foo.war.legacy and the migrated file remains as foo.war
5. The application is reloaded
And on subsequent starts, the migrated application is loaded directly,
with no performance impact.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
