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 > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
