On Tue, Feb 9, 2021 at 10:12 PM Mark Thomas <ma...@apache.org> wrote:
> Hi all, > > I've been looking at the options to integrate the Java EE to Jakarta EE > migration functionality into Tomcat 10. > > There are essentially two ways to do this: deployment time and runtime. > > The simplest solution to implement is probably a separate webapps-legacy > directory (or some other name) where WARs and DIRs added to that > directory get converted to Jakarta EE with the new version being placed > in the webapps directory. There are complexities (such as handling an > updates of the legacy WAR) but they should be manageable. > > A more complex version of the deploy time solution has the legacy web > application placed in webapps, identified as a legacy webapp and then > replaced with the new version (several ways to do this). The hard part > here is the identification of the webapp as a Java EE app. The only > reliable way to do this is class scanning and that is slow. > > The runtime approach converts classes and static resources as they are > loaded. The classes are relatively easy to handle. A > ClassFileTransformer can be added to the WebappClassLoader to do this. > The static files are more of a problem. The good news is that the > WebResources refactoring means static file access all goes through the > same code but the filtering required essentially means we'd need to load > static files into memory - regardless of size, convert them, and then > update the cache with the converted version. That is likely to have a > performance impact. > > Because of the performance impacts of handling static resources, the > runtime approach also needs a way to identify applications that need > conversion. I don't see a reliable, performant way to do that. Which, I > think, leaves us with the simple deployment time approach and something > (filename, special directory, something else) to mark an app as needing > conversion. > > A final point, which probably should have been first, is is there a > demand for this feature? Early indications from the users list and $work > is that there is (going to be) a demand for this feature. > > Thoughts? > Overall it seems more people would like it now, for various reasons. However, there's zero consensus on how since everyone came up with a different idea. I'd like to note the tool is the appropriate solution for most cases, so we cover that already. The main problem with the tool is the perceived effort from users. After reading everything, I'd say it's worth adding a second integrated option, and think I'm now swaying towards the runtime option. The main problem would be the detection of legacy webapps. We could simply mandate using an explicit new attribute on the Context element (and done !) so nobody pays any needless costs. Rémy > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
