On Tue, Feb 9, 2021 at 14:34 Rémy Maucherat <r...@apache.org> wrote:
> 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? > > > > I kind of proposed the "simplest" option [the one using a separate appBase > for the EE 8 and earlier webapps] a couple times. A slightly more complex > deploy time option could look more polished and maybe preferable, like that > "filename" idea maybe ? Or a marker file ? I'm not sure. > > There's a demand for the feature for sure, but probably only up to the > point people realize it's not actually that helpful. This adds a step to > deployment which may fail. The offline tool however is more efficient and > safer. Also the tool now has quite a few "advanced" options [the ones you > just added] for migrating trickier webapps, so how is an automatic > migration with defaults going to work out ? This looks like asking people > to fill up the BZ with stuff. > > So assuming the feature goes in, maybe a hybrid solution could work better > than a pure runtime or deploy time solution. The classloader classes and > resources could rely on a runtime conversion [a bit costly but probably > safer], while the static resources could be converted at deployment time > [it's hard to give decent guarantees on resource use if done at runtime]. > > Rémy We’ve spent two decades optimizing the run time within the constraints that the Servlet spec has given to us. This was driven by the market, and accentuated when containerization became a thing. I would suggest that those optimization not be lost and that the extra time spent at startup, a highly repetitive operation these days, would be something the user would have to opt in to. Personally I like a complete offline model, yet there is immense value for organizations that have stale projects to be upgraded easily. (albeit, one can argue they can stay on v9 for a very long time too) > > > > > > Mark > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > >
