Hi, I'd go simple:
1. Add in the tool jar a ClassFileTransformer 2. Make this transformer configurable (packages using "startsWith" which is fast and optimizable - maybe something like https://github.com/apache/openwebbeans-meecrowave/blob/master/meecrowave-core/src/main/java/org/apache/meecrowave/openwebbeans/KnownClassesFilter.java#L218 ) 3. Add a transformer webresource - like in maven shade plugin - which is about to transform a resource from a pattern (prefix/suffix cases being optimized in terms of matching) and replacement With these 3 new configurable classes tomcat stays pure and fast for all cases but enables the migration on the fly when needed. Can even be a tomcat-jakarta-migration-helper.jar totally independent of tomcat - while it is released on central from time to time ;). All mecanism requiring another webapp or a reload are promises of failures IMHO since often webapps are dropped or undesired except the app webapps in real or dev deployments. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 10 févr. 2021 à 01:46, Emmanuel Bourg <ebo...@apache.org> a écrit : > 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 > >
