Le mer. 10 févr. 2021 à 09:32, Martin Grigorov <mgrigo...@apache.org> a écrit :
> Hi, > > On Tue, Feb 9, 2021 at 11: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? > > > > We should also think about Tomcat Embedded! Many of the modern web > frameworks use embedded Tomcat/Jetty/Undertow. > I guess it should be even easier for them to set a property saying "I need > this app to be migrated" or to put it in the special folder > (webapps-legacy/). > We just need to make sure tomcat-embed is taken into account for the > eventual solution! > I'm actually not sure: 1. embed case almost never have a webapps/ folder and always uses flat classpath so only option is a javaagent but 2. 2. embed case does not have this standalone status where you put an app in another one so if you want to change you change it in your build I can see you speaking of spring-boot or so but this is all solved by maven shade plugin or gradle equivalent task so I wouldn't invest in a solution which - for this case - wouldnt be used compared to the standalone case which still has ops vs dev coverage and need IMHO. > > Martin > > > > Mark > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > >
