Le mer. 10 févr. 2021 à 16:37, Rémy Maucherat <r...@apache.org> a écrit :
> 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. > s/attribute/listener/ ? the context listener can install the class file transformer + webresource filter wrapper programmatically and is a one liner for end user. Wdyt? > > Rémy > > > > > > Mark > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > >
